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

Hi,

On Jan 18, 2006, at 3:39, Ted Faber wrote:
>
> I'd like to start a WG last call for the DCR document for  
> protecting TCP
> from reordering from Bhandarkar, Reddy, Allman, and Blanton.
...
> 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.

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

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

Attachment: smime.p7s