[Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?

Yuchung Cheng ycheng at google.com
Fri Sep 7 23:49:01 BST 2012


I am glad we all identify the problem about FlightSize. We need a
better mechanism to address application-limited cases, i.e., when cwnd
is not fully used recently.

within an RTT or so:
a) loss: halve cwnd or flightsize or something else?
b) no-loss: grow cwnd or not?

longer than several RTTs (idle)
c) decay the cwnd every couple minutes or every couple RTO, slow-start
to prev cwnd, blah?

There is always a concern about potential bursts leaving cwnd >>
FlightSize. So RFCs and implementations drag cwnd to "moderate"
potential bursts. For example, Linux pulls cwnd down to FlightSize +
epsilon whenever an ACK does not look right, and refuses to grow cwnd
unless it was fully used. And most congestion control design does not
consider these events.

I don't know what the right solution is yet. Pacing + track inflight
of last RTT?

but I know app-limited cases happen a whole lot today. Beside HTTP or
RPCs (in data centers), even video deliveries are interactive, e.g.,
NetFlix or Youtube. The apps pace at second(s) interval to conserve
network bandwidth. And TCP-smart apps all use persistent connections
today. TCP usage has moved away from bulk-ftp long time...

Yuchung



More information about the Iccrg mailing list