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

[[e-mail] (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
>From [e-mail]  Thu Sep  6 23:05:32 2012
From: [e-mail] (Mark Allman)
Date: Thu Sep  6 22:58:09 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>


> 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 agree with that.

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/ed22f0ba/attachment.bin
>From [e-mail]  Thu Sep  6 23:50:34 2012
From: [e-mail] (Matt Mathis)
Date: Thu Sep  6 23:42:53 2012
Subject: [Iccrg] Re: [tcpm] RFC5681: why halving FlightSize not cwnd?
In-Reply-To: <[e-mail]>
References: <CAK6E8=[e-mail]>
	<[e-mail]>
	<[e-mail]>
Message-ID: <CAH56bmDP5YwGqpfDQ5=OGceohx+xrsoOSDkd7RZHg7O=V=[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