[Tsvwg] Re: HighSpeed TCP for Large Congestion Windows

Reiner -

>I have few comments about that draft ...
>
>1. I'm not convinced that this is a real problem for the (public) Internet:

As I said in the viewgraphs, I certainly don't think this is a
pressing problem in the Internet today, for anyone.  The HighSpeed
TCP draft tried to be clear about the problem description, which
is the *very* small packet drop/mark rates needed to sustain very
high congestion windows with current TCP.  

The reason to bring this to tsvwg is exactly to hear whether people
feel this is inappropriate to bring to the IETF, or not.  (My own
reading of the sense of the working group meeting was that people
felt that this *was* appropriate to bring to the IETF.)

>- Applications that only send a few 10 Gigabytes every now and then won't 
>benefit from HighSpeed-TCP since the TCP sender will have to reset, or at 
>least decay its congestion window during the idle phases. Such applications 
>suffer most of all from the slow start.

The Quick-Start draft tries to address this issue.

>- In a regime of CWNDs on the order of 100.000 segments (probably even 
>sooner), why would a single packet loss per window be treated the same as a 
>loss of half a window worth of segments? This was always something that 
>bugged me about TCP-SACK.

Actually, TCP-SACK doesn't respond the same to those two cases.  It
is true that it only halves its congestion window once for a
round-trip time, regardless of the number of losses or marks in
that window of data, as did Tahoe TCP before it in 1988, and as
seems quite correct to me.  But SACK TCP is ACK-clocked even during
Fast Recovery, and does respond somewhat differently to one loss
than to half a window of losses.

draft-allman-tcp-sack-12.txt of course has the current-best-practice
for SACK TCP.

- Sally

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg