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

[Yuchung Cheng]

On Thu, Sep 6, 2012 at 12:08 PM, Ethan Blanton <eblanton at cs.ohiou.edu> wrote:
> Yuchung Cheng spake unto us the following wisdom:
>> RFC 5681 specifically calls to use FlightSize instead of cwnd for cwnd
>> reduction.
>>
>> """When a TCP sender detects segment loss using the retransmission timer
>>    and the given segment has not yet been resent by way of the
>>    retransmission timer, the value of ssthresh MUST be set to no more
>>    than the value given in equation (4):
>>
>>       ssthresh = max (FlightSize / 2, 2*SMSS)            (4)
>>
>>    where, as discussed above, FlightSize is the amount of outstanding
>>    data in the network.
>>
>>    [...]
>>
>>    Implementation Note: An easy mistake to make is to simply use cwnd,
>>    rather than FlightSize, which in some implementations may
>>    incidentally increase well beyond rwnd.
>> """
>> When a sender sends cwnd==20 packets
>> a) fast-recovery: only 17th packet got dropped. FlightSize == 4
>> (pipe==1), ssthresh=2
>> b) timeout: 17-20th packets are dropped. FlightSize == 4(pipe==4), ssthresh=2
>
> Note that this is _only_ true if there were only 20 segments available
> to send.  Otherwise, by the time the dup ACKs for 17 come in, up to 32
> (remember ssthresh!) new segments would have been clocked out.  So
> your sender is either data-limited or protocol-limited or some such.
This is unfortunately the case of trillions of HTTP flows or any RPC
 interactive type traffic today. It's not a corner case.

>
> What that means is, in your scenario, where FlightSize == 4, at the
> time that packet 17 was dropped, your TCP's contribution to the
> network traffic was only 4 packets.  Therefore, as far as it can tell,
> a burden of 4 packets is "too much".

so if I send 100 packet (then stop) and only the last 1 got dropped. I
 should start from ssthresh == 2? isn't it more reasonable to assume
100 is too much, not 1 is too much?

then I am kinda unfortunate if the next some data is ready to send 1 RTT
after the one packet loss is recovered.

and I still don't get the rationale of rwnd argument in RFC 5681.

>
> Yes, this is over simple and probably not the case -- but we're also
> talking about a corner case, here.  Since you don't have any new data
> to send, anyway, you'll retransmit 17, get an ACK for 20, and close
> the connection or wait for new data or whatever.
>
> Ethan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEVAwUBUEj0tP8fixZ3H8crAQjFCgf/XRxoG+d3G1Hk7baB3tMht2Vgwx6VrTu/
> daL2bOLuabBjAySKUp1ouBtmaAJUs40Il1w9cdyQrcJ99NUxqpBywB2goLTxsdPQ
> xkdjzHXI52upeg2bgDBtamc7T+qsSiDkyCzNpWUG8FdPPAqC7lGoL0Xe8OlOFET5
> FfgeCH/K1Z+wsI05ykNe8Vv9Shx1/CJnWXjJ86DUNZl56qXqpENmLAvDdgQLe4AK
> H8BZgG6Ij66Vii8Al8Tu8ndK2HMMO8JnYIIEbj9gASHCusB2ZqdopA7xg8GCaMKM
> E641K5C5mRpyQE6yR/ORlE6xIL243ARsiM9Sfv0S30hoMmNn5ll71Q==
> =HJZ1
> -----END PGP SIGNATURE-----
>