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

[Matt Mathis <[e-mail]>]

On Thu, Sep 6, 2012 at 2:25 PM, Ethan Blanton <[e-mail]> wrote:
> Mark Allman spake unto us the following wisdom:
>> 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.
>
> Note that this was not intended to be my argument; my argument is that
> a TCP that doesn't "remember" such things (and 5681 does not) only
> knows about the 4 packets at the time of the loss, so it *thinks* the
> burden is 4.  This is clearly not optimal, and I would not argue that
> it is.  Perhaps I stated this poorly.

I would say that you are using the wrong state variables:  at this
point cwnd is simultaneously being used to suppress bursts and
remember the congestion state from before the application pause.   If
you parameterize it differently (e.g. Laminar) this becomes a
non-problem.

>>   - 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.
>
> Agreed.

Yes exactly.   One solution would be to pace from FS up to ccwind....
This case is described in the Laminar draft.

>>   - 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.
>
> Also agreed.  I think it's reasonable to assume that the FlightSize in
> effect at the time a lost packet was *sent* is safe, for sure.

I point out this logic assumes that it was the instantaneous queue
length that triggered the losses (as it is for drop tail).  With RED
or CoDel, the losses are normally triggered by a persistent queue,
which may or may not depend on the instantaneous window at the time
the packet was either sent or received.   With CoDel, drops are
triggered when the minimum window size is still large enough to
sustain a queue....  The peak window has no effect on the drops
(unless the queue overflows).

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay