Re: [tcpPrague] Experimental dual-queue ECN

[Michael Welzl <[e-mail]>]

how nice to see, we all agree!

Sent from my iPhone

> On 25. jun. 2016, at 16.20, Gorry Fairhurst <[e-mail]> wrote:
> 
> Email is a wodnerful media... we seem to have a lot more agreement than I'd hoped.
> 
> (... and yes: If we have more than one simple PS update to 3168, and everyone agrees, I think these could form part of the same document).
> 
> Gorry
> 
>> On 25/06/2016 15:08, John Leslie wrote:
>>    I seem to have flunked Robert Heinlein's class in writing orders!
>> 
>>    Gorry succeeded in misunderstanding my point 1: "that reaction to ECN-CE
>> should be the 'same as' drop". :^)
>> 
>>    It was "obvious" to me that RFC 3168 now requires that, and that we
>> need to change so that is no longer required.
>> 
>>    Fortunately, it seems the three of us agree it needs to change. :^)
>> 
>> Michael Welzl<[e-mail]>  wrote:
>>> From: Michael Welzl<[e-mail]>
>>> ...
>>>> On 24. jun. 2016, at 19.41, Gorry Fairhurst<[e-mail]>  wrote:
>>>> ...
>>>> On 24/06/2016 18:01, John Leslie wrote:
>>>>> Spencer Dawkins at IETF<[e-mail]>   wrote:
>>>>>> ...
>>>>>> Are you thinking that wouldn't work here?
>>>>> IMHO, such a path to  update RFC 3168 is impractical.
>>>>> ...
>>>>> IMHO, we need to break off a limited part of it for Experimental
>>>>> protocols:
>>>>> 
>>>>> 1. that reaction to ECN-CE should be the "same as" drop; and
>>>> I disagree of course - the CE-marking proposal has already been
>>>> discussed at the IETF - and I suggest no ECN is likely to be foundi
>>>> using RED - and ECN-marked RED is now anyway now deprecated.
>>>> Many modern AQM methods CE-mark on a shallow queue - and I think
>>>> we need to update the PS to reflect this.
>>    Fundamentally, I agree: but my concern was the minimum change needed
>> to 3168.
>> 
>>> +1 to Gorry  (unsurprisingly).
>>> 
>>> The ECN ???Experiment??? has hardly happened, so on what basis de
>>> we say that a reaction that is the ???same as??? drop is safe?
>>    IMHO, that is what 3168 meant to say. I've never agreed with it.
>> 
>>> If we just take operational experience, Cubic has first used a backoff
>>> (multiplication) factor of 0.8, then 0.7, deployed in Linux and widely
>>> used in the Internet.
>>> This isn???t even limited to an ECN signal, which is likely to be
>>> produced by an AQM mechanism, and hence much more likely to indicate
>>> a shallow queue than loss.
>>    I agree.
>> 
>>> So: I think we can now assert that the Internet won???t melt down if
>>> we'd back off using a different multiplication factor than 0.5.
>>    I agree that would be good background material for a PS RFC relaxing
>> that rule of 3168.
>> 
>>    (But I don't think we need to limit the difference to applying a
>> differentt factor: that is a really obvious way, and it has effectively
>> been tested in actual use; but it is not the _only_ way.
>> 
>>> Using such a larger factor *only* in response to ECN is even more
>>> conservative, so even safer.
>>    Exactly!
>> 
>>> Adding to this, what exactly is the logic that makes ???react to
>>> marking the same way as you would react to drop??? particularly safe?
>>    The argument, as best I recall, was that otherwise one flow would
>> starve the other. But there are other ways to treat that problem!
>> 
>>> I can only assume that this assumes the same behavior in the network
>>> for ECN-marking and dropping, and so, if we keep as much as possible
>>> similar, this would be a safe way to go.
>>    I don't see any reason to "keep as much as possible similay" if
>> it's for an Experimental RFC. We should aim for _significant_ improvement.
>> 
>>> Reality is different. Please see, for example Figure 13 in this pdf:
>>> https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.pdf
>>    I shall get around to reading this today.
>> 
>>> ...
>>> In conclusion, I struggle to see the big reason why an ???exactly like
>>> loss??? backoff is standard behavior and experimenting with other values
>>> should be prohibited.
>>    We three agree it shouldn't.
>> 
>>    But...
>> 
>>    Implementors should be able to read RFC3168 and its metadate and
>> understand that their ten-year-old code may no longer be compliant.
>> 
>>    It's about a warning-label!
>> 
>>> A new particular value may constitute an experiment, but the
>>> ???equal to loss??? limitation simply isn???t a good thing and should
>>> be removed - this removal isn???t an experiment, it's a bugfix.
>>    Exactly!
>> 
>>> ...
>>>> I also don't see a specific experiment that is needed here  - what
>>>> would be needed to test for safety in deployment? I *think*
>>>> particular update can be taken directly to PS.
>>> +1
>> 
>>    (I believe we could treat two issues in the same RFC, in order to
>> make implementors' jab a little easier. YMMV...)
>> 
>>> ...
>> --
>> John Leslie<[e-mail]>
>