Re: [tcpPrague] Experimental dual-queue ECN

+1 on a simple draft to revise RFC 3168 solely to clear the "space" needed
for this sort of experimentation without getting into any details of what the
experiments will or will not do (NB: that sort of speculation on what's coming
is part of what got the RTP circuit breaker draft into its current situation, so
let's not repeat that ...).

Thanks, --David


> -----Original Message-----
> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Michael
> Welzl
> Sent: Saturday, June 25, 2016 6:44 PM
> To: gorry@erg.abdn.ac.uk
> Cc: Bob Briscoe; John Leslie; Spencer Dawkins; TCP Prague List
> Subject: Re: [tcpPrague] Experimental dual-queue ECN
> 
> how nice to see, we all agree!
> 
> Sent from my iPhone
> 
> > On 25. jun. 2016, at 16.20, Gorry Fairhurst <gorry@erg.abdn.ac.uk> 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<michawe@ifi.uio.no>  wrote:
> >>> From: Michael Welzl<michawe@ifi.uio.no>
> >>> ...
> >>>> On 24. jun. 2016, at 19.41, Gorry Fairhurst<gorry@erg.abdn.ac.uk>  wrote:
> >>>> ...
> >>>> On 24/06/2016 18:01, John Leslie wrote:
> >>>>> Spencer Dawkins at IETF<spencerdawkins.ietf@gmail.com>   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<john@jlc.net>
> >
> 
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague