Re: [tcpPrague] Experimental dual-queue ECN

[Gorry Fairhurst <[e-mail]>]

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]>