Subject: [tcpm] WGLC: NCR draft-ietf-tcpm-tcp-dcr-06.txt ENDS 27 Jan 2006

From: Ted Faber <[email-masked]>
Date: Tue, 17 Jan 2006 18:39:19 -0800

Hi.

I'd like to start a WG last call for the DCR document for protecting TCP
from reordering from Bhandarkar, Reddy, Allman, and Blanton.

	Title		: Improving the Robustness of TCP to
			  Non-Congestion Events
	Authors		: Sumitha Bhandarkar, et al.
	Filename	: draft-ietf-tcpm-tcp-dcr-06.txt
	Pages		: 17
	Date		: November 2005
	http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-dcr-06.txt

This draft is chartered to become Experimental.  I understand that all
the feedback to date, from the list and privately communicated, has been
incorporated into the document.  Further, I believe that the technical
opinions as expressed have been largely in favor of this draft becoming
Experimental.  Now is the time to speak up if you disagree or feel that
there are outstanding technical points that remain unaddressed in the
document.

Because this is starting mid-week, I'm extending the WGLC period for a
couple days.  Final day for comments is Friday 27, 2006 at midnight PST
(but I'm not going to be picky over an hour).

Please take some time to read it.  Please take some time to send
feedback to the list or to me.  As with all TCPM documents, there needs
to be a demonstration that the document has some support from the group,
so even a message that says "ship it" is helpful.

Also note that Mark is one of the authors, so I'm handling all the chair
stuff for this one, including an idnits pass and all the admin. 

Thanks for your help.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Lars Eggert <[email-masked]>
Date: Fri, 20 Jan 2006 18:27:55 +0100

Hi,

> from reordering from Bhandarkar, Reddy, Allman, and Blanton.
...
> so even a message that says "ship it" is helpful.

I gave it a quick read and I think it is in pretty good shape generally.

Given that the text repeatedly states that the impact of this on the  
general Internet is not really known, I assume this is going for the  
"experimental in the sense that we want to experiment with it"-flavor  
of Experimental? If so, stating prominently in the abstract and maybe  
introduction that this is not ready for production use may be a good  
idea.

One question regarding fairness: If there's a DCR flow and a non-DCR  
flow sharing a path that reorders packets a bit, wouldn't the  
reordering tolerance of the DCR flow cause it to steal bandwidth from  
the non-DCR flow? The paper says "it is to be noted that the reason  
for TCP-DCR realizing better throughputs (when packets are reordered)  
is not due to unfairness, but due to correctly recovering from the  
reordering events." Maybe I'm dense, but I don't see the experimental  
data to back this up. Is the throughput for SACK shown in Figure 4  
identical when competing only against other SACK flows? Is the  
dynamic behavior roughly the same?

Nits:

overall, the specification parts of the document could try to use  
RFC2119 terms a bit more explicitly

page 1: "mild reordering" - maybe _minor_ reordering?

page 3/4: "schemes proposed for differentiated services architecture"  
- for _a_ diff. serv. arch.?

page 4: "in the face of packet reordering three duplicate" - in the  
face of packet reordering, three duplicate

(Similarly missing commas in many places throughout the document;  
need to read many sentences twice to grok the meaning.)

page 10: s/algoritms in [RFC3517]/algorithms in [RFC3517]/

page 11: s/that the additonal buffer/that the additional buffer/

page 12/13: section 6 & its related work references could be removed  
for RFC publication

ref BPS99: s/is not pat hological/is not pathological/

ref KM02: s/twostage switche s/twostage switches/

Lars
--
Lars Eggert                                     NEC Network Laboratories

---

From: Mark Allman <[email-masked]>
Date: Fri, 20 Jan 2006 15:17:41 -0500

Lars-

Thanks for the comments.  I'll fix up the nits, thanks!

> of Experimental? 

Yes.

In fact, the really experimental part of it to me is that using
Aggressive Limited Transmit delays the congestion response by an RTT.

(To a lesser degree even the Careful variant of Limited Transmit removes
the standard idle period between detecting "congestion" and resuming
transmission.  But, this seems sort of minor to me.)

> If so, stating prominently in the abstract and maybe introduction that
> this is not ready for production use may be a good idea.

Good call.  I'll add a note.

> One question regarding fairness: 

I am confused about what you're reading here.  I.e., the draft has no
figures, the quote below isn't from the draft and I don't think we even
discuss fairness in the i-d.

> If there's a DCR flow and a non-DCR flow sharing a path that reorders
> packets a bit, wouldn't the reordering tolerance of the DCR flow cause
> it to steal bandwidth from the non-DCR flow?

This is not clear to me.  In fact, it's not clear to me exactly how
fairness comes into this.  If there were 2 flows over some path and no
reordering then we'd expect them to see about the same performance
(about half the bandwidth).  Now, if there was reordering and neither
did NCR then they would each get less than half the bandwidth -- say
they each got 1/4 the bandwidth, just to put some numbers on things.
So, now the reordering is causing a 50% slowdown in the flows and less
than full utilization.  Now, if one of the flows were to use NCR and it
were to get more than 1/4 the bandwidth that would seem fine to me.
And, in fact, the NCR flow could get up to 3/4 of the capacity and I
wouldn't think that was unfair at all --- even though the rates are
quite different.  I.e., the NCR flow is using what is available.  Now,
if the NCR flow ended up with 7/8 of the capacity and drove the non-NCR
flow to 1/8 of the capacity ... well, then there is a question.  In some
sense, the NCR flow is stealing from the non-NCR flow, for sure.  Will
this happen?  I am not sure.  Is there a way to minimize it?  I don't
know.  Is this a natural part of trying to make progress and an
incentive for stacks to combat reordering?  Perhaps.  This could all be
part of the experiment. 

> The paper says "it is to be noted that the reason for TCP-DCR
> realizing better throughputs (when packets are reordered) is not due
> to unfairness, but due to correctly recovering from the reordering
> events." Maybe I'm dense, but I don't see the experimental data to
> back this up. Is the throughput for SACK shown in Figure 4 identical
> when competing only against other SACK flows? Is the dynamic behavior
> roughly the same?

Where is this from?

Thanks again!

allman

---

From: Lars Eggert <[email-masked]>
Date: Fri, 20 Jan 2006 21:56:32 +0100

Hi,

> discuss fairness in the i-d.

oops, I meant to add that I got this from [BR04] before I hit  
"send." (I started thinking about the fairness stuff when reading the  
draft and then dug through the refs to find an evaluation.)

> (about half the bandwidth).

Yup.

>   Now, if there was reordering and neither

Yup.

> quite different.  I.e., the NCR flow is using what is available.

Right - iff the other flow still got its 1/4. I'm wondering if this  
will always (or at least usually) be the case. What if we had a long,  
fat path where the non-DCR flow would need a long time to get back to  
1/2 - could the DCR flow actually delay that even more? Maybe not or  
not by much, but I'd still feel better if there was some sort of  
experimental results.

>   Now,

Right, that was sort of what popped up in my head when reading this.

>> when competing only against other SACK flows? Is the dynamic behavior

Sumitha's Networking 2004 paper [BR04], but I just saw in Section 4  
that the mechanism may have changed since then - that pub was about DCR.

Also, note that I don't think this question is a showstopper for  
going forward with the draft as Experimental. It's one more question  
that should be looked at when experimenting with this.

Lars

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 20 Jan 2006 13:31:32 -0800

Awesome footwork, Mark!

I've been out of the loop for a while, so can someone
please refresh me on the requirement for fairness.

I understand the requirement to prevent the next
Internet meltdown, but not a requirement for fairness.

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 21 Jan 2006 20:26:16 +0000

Mark Allman wrote:
> than full utilization.

Wait - you're arguing too far from an assumption, I think.

Does reordering have as bad an effect on a congested link
as on an uncongested link?  Or is it more like a 5% penalty
(congested) and 50% (congested).   If so, there's potential
for NCR to improve the situation for the flow using it to,
say, 3/4 of the bandwidth - leaving the non-NCR user only
getting 95% of 1/4 of the bandwidth.

Possibly this is what you mean later:

 >flow to 1/8 of the capacity ... well, then there is a question.

and I didn't see the steps in your reasoning.  I'd call it unfair,
but justified.

In any case, I'm not arguing against the draft becoming Experimental.

Cheers,
     Jeremy Harris

---

From: Mark Allman <[email-masked]>
Date: Mon, 23 Jan 2006 09:40:59 -0500

> oops, I meant to add that I got this from [BR04] before I hit "send."
> (I started thinking about the fairness stuff when reading the draft
> and then dug through the refs to find an evaluation.)

Thanks.

I looked over the paper and I agree with you that the results in that
paper do not specifically address the question you're asking.

> that the mechanism may have changed since then - that pub was about

Right.

> Also, note that I don't think this question is a showstopper for going
> forward with the draft as Experimental. It's one more question that
> should be looked at when experimenting with this.

Great, thanks for the clarifications and the comments!

allman

---

From: Mark Allman <[email-masked]>
Date: Mon, 23 Jan 2006 09:52:50 -0500

> Internet meltdown, but not a requirement for fairness.

I am not sure there is a "requirement for fairness".  It's certainly a
little bit of a fuzzy issue in a case like NCR tries to combat.  For
instance, say over a given path two flows can get X bps given the
current congestion and reordering state of the network.  But, if NCR is
used on one flow and that flow gets 3*X bps and the first flow still
gets X bps is that unfair?  For sure the flows have different rates.
So, using something like Jain's fairness index (i.e., just measuring the
spread of rates amongst all flows) might say this is unfair.  But, to
me, neither flow is sending at an inappropriate rate for the given
context.  I.e., the flow sending at X bps cannot send any faster and the
flow sending at 3*X bps is just using what is available.

(Another example of this would be one flow using an advertised window of
Y and another using 5*Y and obtaining better performance.)

Of course, it gets thornier if the flow that gets 3*X bps ends up
stealing some of those bps from the other flow such that it sends at N*X
(for some N < 1).  Now, the reordering robust flow is not just using
spare capacity, but also getting some of its performance boost at the
expense of the non-NCR flow.  We might say that is unfair and say we
have to try to design something into NCR to avoid this - or, largely
mitigate it.  On the other hand, we might decide that the disadvantage
is not great and that this is part of the natural evolutionary path of
TCP, whereby older TCPs don't compete as well as newer TCPs and
therefore, we view this as an incentive to upgrade.  This would be a bit
of engineering judgment after we have a solid set of experiments to look
over, IMO.

allman

---

From: Mark Allman <[email-masked]>
Date: Mon, 23 Jan 2006 09:56:31 -0500

> as on an uncongested link?  

My own guess is that on a congested link the congestion would have more
of an impact than reordering.  I think that if reordering ends up being
the dominant phenomenon then the path will not be (as) congested because
of the slow downs from false congestion signals.

But, this would clearly be something to look at with real measurements
and not just wave one's hands over as I am doing.

> In any case, I'm not arguing against the draft becoming Experimental.

Great, thanks!

allman

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 23 Jan 2006 10:05:20 -0500

> of engineering judgment after we have a solid set of experiments to look

More compactly, the question is how closely NCR can achieve a Pareto
optimum, or max-min fairness, in competition with other types of flows.

-Wes

-- 
Wesley M. Eddy
Verizon Federal Network Systems
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Ted Faber <[email-masked]>
Date: Mon, 30 Jan 2006 09:25:01 -0800

> (but I'm not going to be picky over an hour).

Having watched the discussion and spoken with Mark about any off-list
interaction, it seems clear to me this dosument has passed WGLC.  Minor
issues were raised and dealt with during the WGLC, but no showstoppers
surfaced.  No one argued that the draft should not move to experimental.

If I've missed comments, or you disagree with my assessment of
consensus, I'd like to hear ASAP.

Thanks to everyone who participated in the creation and review of this
document.