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

[Mark Allman]

A few things ...

  - I don't buy Ethan's argument that the burden on the network is 4
    packets if you lose the 17th.  It seems to me the burden is measured
    from the front of the window not the back.  So, in this case it was
    a burden of 17 packets that caused the loss.

  - The historical reason why we use FlightSize instead of cwnd is that
    cwnd was not always reflective of the burden placed on the network.
    For instance, some implementations just let the cwnd grow without
    bound regardless of whether it was used or not.  So, the cwnd might
    be (say) 100 even though you have never sent more than 20 segments
    per RTT when you go to set ssthresh.

  - (The note about the rwnd is not elegant!  All we mean is that the
    cwnd is growing without being used and, hey, it could even grow
    higher than the rwnd.  But, really who cares about the rwnd ... the
    point is that it grows unused and so is not reflective of anything.)
    
  - I may well buy that the current scheme leaves us too conservative
    due to cases like you sketch.  Exactly how important this case is
    I'll leave to you and Ethan to fight out! :-)

  - So, without additional schemes we're left with being too aggressive
    (using cwnd) or too conservative (using FlightSize).  But, if we're
    going to error that is probably the right direction.

  - I probably would not have all that much heartburn making the
    ssthresh 10 in the case you describe as long as there was some
    knowledge that a cwnd of 20 was used recently.  I.e., it isn't the
    result of some large storage of permission to send that was built up
    over time, but was in fact the result of the application's sending
    pattern.  I think one could design some rules around that notion
    that would be OK.

allman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20120906/e860829e/attachment.bin