[Iccrg] Review draft-fairhurst-tcpm-newcwv-03

[[e-mail] (Mirja Kühlewind )]

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