[Iccrg] Review draft-fairhurst-tcpm-newcwv-03
Mirja Kühlewind
mirja.kuehlewind at ikr.uni-stuttgart.de
Wed Jul 18 18:55:14 BST 2012
Hi Gorry,
I believe this draft addresses a very important problem which exists and need
to be solved. But I'm not too sure about the solution that is proposed. But I
also don't know what the right/perfect solution would be.
My biggest concern is regarding potential bursts you might introduce. Maybe
I'm too conservative but I believe whatever you gone chance in TCP, one thing
to avoid is the chance to cause large bursts of packets. Recently, it was
actually recognized that the block sending behavior of youTube (eventough it
is using normal standard-conform TCP) leads to bursts and large loss
probabilities. Actually that is a problem that exists in today's TCP and
needs to be addressed too.
So I guess what I propose is to limit the burst size. This is not completely
though through yet but you could allow some slow start like behavior in CA if
the flow has been application limited. So maybe your mechanism could be
extended to allow only bursts of 2 (or 3) packets. That would mean that you
would be able to increase your sending rate form 1*flightsize to 2*(or
3*)flightsize in one RTT if the flow was application limited before. Don't
you think that might be already sufficient?
In case of idle times this would (unfortunately) lead back to normal slow
start behavior but the IW10 draft also specifies a restart window of 10. This
might help the problem already a lot...?
Btw. in Linux (and potentially in some RFC?) there is already a maximum burst
size of 3 implemented but this is only used to limited the congestion window
to flightsize + maxburstsize.
I will send some more detailed comments on the draft tomorrow (don't have my
notes with me at the moment). But one more point are the values you have
chosen for the several thresholds. I know there is a whole section reasoning
why 5 minutes have been chosen but that didn't really convince me.
One more though on my proposal above (which is still not though through): If
you would track the max cwnd since the last congestion notification event and
use this as a threshold upto which the kind of slow-start-behavior in CA (as
explained above) is allow, I don't think that there is any time limit needed
at all...
I guess this whole idea leads to something similar as proposed by TCP Laminar.
As Yuchung mentioned those two proposals should be regarded together.
Some more detailed comments tomorrow...
Mirja
More information about the Iccrg
mailing list