Re: [dccp] dccp spec expert review (Minshall, main spec)

[Sally Floyd <floyd@icir.org>]

Greg -

Many thanks, again, for the helpful feedback.

...
>in summary, i would say the three biggest issues are: sequence number 
>wrapping; making sure half-open connections close nicely; and how to treat 
>congestion interior to the receiving node.

I am just going to address the third issue, how to treat congestion
interior to the receiving node, in this note.  I would say this is
a significant issue, and that we disagree.

...
>> Congestion in the receiving node does not always merit the same heavy-duty
>> response as network congestion.
>
>i'll repeat that i think this a mistake.  at some extreme we would both agree 
>to be idiotic there could be separate mechanisms depending on if it is the 
>sending NIC, receiving NIC, receiving kernel buffer space, receiving kernel 
>disk bandwidth for paging, etc., that is congested.
>
>we have a mechanism for dealing with congestion, which is dropping (or, if we 
>are able, marking but forwarding) packets which encounter that congestion.  it
 
>is conceptually simple.  i strongly suggest staying with this.  (i guess i've 
>belabored this point.)

One question would be whether this has been established as the
appropriate response for TCP.  If it had, then DCCP could be expected
to either follow suit, or to argue why it was not following suit.
However, I don't believe that this has been established as the
appropriate behavior for TCP, or for transport protocols in general.

There is code exactly like this in Linux, I believe, to reduce the
congestion window in response to congestion interior to the end
nodes, and the highspeed TCP gang has had a fair amount of trouble
with it.  The problem occurs when you need a very large window of
W segments to utilize the bandwidth of your path, and TCP halves
its congestion window in response to a buffer problem in the end
node.  It takes the TCP connection W/2 round-trip times to recover
back to its old congestion window, and this can be a very big
performance hit if W is large.  Not too good, for a TCP connection
that would need to build up to a large congestion window to use the
available bandwidth.

For my thoughts on the other code in Linux to reduce the congestion
window for things that are not congestion events in the network itself,
you could look at my 5/14 email to tsvwg, 
"http://www1.ietf.org/mail-archive/working-groups/tsvwg/current/msg04086.html";.
I think it is a pretty bad idea.

- Sally
http://www.icir.org/floyd/

_______________________________________________
dccp IETF mailing list: dccp@ietf.org
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html