Re: [aqm] adoption call: draft-welzl-ecn-benefits

[[e-mail]]

Please see some thoughts below.

> On Tue, Aug 12, 2014 at 3:24 AM, Gorry Fairhurst <[e-mail]>
> wrote:
>> OK, so I have many comments, see below.
>>
>> Gorry
>>
>>
>> On 12/08/2014 10:43, Bob Briscoe wrote:
>>>
>>> Wes, and responders so far,
>>>
>>> A doc on the benefits and pitfalls of ECN is needed. Personally I
>>> wouldn't assign much of my own time as a priority for such work; I'd
>>> rather work on finding the best road through the protocol engineering.
>>> But I'm glad others are doing this.
>>>
>>> We need to be clear that this doc (at the moment) is about the benefits
>>> of 'something like RFC3168 ECN'. I think that is the right direction. I
>>> would not be interested in a doc solely about the benefits of 'classic'
>>> ECN (we had RFC2884 for that).
>>>
>>> However, if it is about the benefits of some other ECN-like thing, it
>>> will not be worth writing unless it is more concrete on what that other
>>> ECN-like thing is. At present different and sometimes conflicting ideas
>>> are floating around (I'm to blame for a few).
>>>
>>> In order to write about benefits, surely experiments are needed to
>>> quantify the benefits?
>
> +10
>
GF: Interesting suggestions, thanks. We'd be happy to see research to
quantify the benefits of specific methods in a range of scenarios. 
However, this draft is intended to be a long-lived document that speaks of
the potential benefits that ECN can offer across the Internet in general.

>>> Alternatively, this could be a manifesto to
>>> identify /potential/ benefits of ECN that the current classic ECN is
>>> failing to give. I think at the moment it's the latter (and that's OK
>>> given that's where we have reached today).
>>>
>> GF: If someone wishes to write this research paper, I'd be happy to join
>> them, but it was not what I had in mind for this ID.
>>
>>
>>> How about the title "Explicit Congestion Notification (ECN): Benefits,
>>> Opportunities and Pitfalls" ?
>>>
>> GF: I could live with that, if the group wished this!
>
> +1
>
>>
>>
>>> We (in the RITE project) have agreed to start work on an 'ECN Roadmap'
>>> in order to identify all the potential ideas for using ECN coming out
>>> of
>>> research, and write down whether new standards will be needed for some,
>>> whether they can evolve without changing standards, which are
>>> complementary, which conflict, etc.
>
> I'd like to see experiments done through the free.fr network as it's the
> only one I know of with ecn enabled along the edge in their revolution
> v6 product.
>
> Presently cerowrt ships with ecn enabled on the inbound rate
> limiter and disabled on the outbound, I have considered enabling
> it by default on the outbound for connections > 4mbits.
> (users can override these settings, of course)
>
GF: Understood.


>>>
>>> I don't know whether this ECN benefits doc ought to include this
>>> detailed ECN roadmap work, but if it's going to talk about "something
>>> like ECN" I believe it will have to include a summary of the main items
>>> on such a roadmap to be concrete.
>>>
>>>
>>> more inline...
>>>
>>> At 00:38 12/08/2014, John Leslie wrote:
>>>>
>>>>    (I have read Michael's reply to this, but I'll respond here.)
>>>>
>>>> Dave Taht <[e-mail]> wrote:
>>>> > On Mon, Aug 11, 2014 at 7:48 AM, Wesley Eddy <[e-mail]>
>>>> wrote:
>>>> >
>>>> >> This draft has been discussed a bit here and in TSVWG:
>>>> >> http://tools.ietf.org/html/draft-welzl-ecn-benefits-01
>>>>
>>>>    I do think this is the right place to discuss it.
>>>>
>>>> >> As I understand, the IAB has also discussed it a bit, and would
>>>> >> be happy if this was something that an IETF working group
>>>> >> published.  I believe the TSVWG chairs also discussed this and
>>>> >> would be fine if the AQM working group adopted it.
>>>>
>>>>    Thus, I am in favor of adopting it, with the understanding that
>>>> it will see significant changes during our discussion.
>>>
>>>
>>> I think we can and should agree the direction of those changes in this
>>> thread. I'd rather not agree to start on a doc and plan to meander.
>>>
>> GF: +1, we can add comments to the ID to align to this, personally I've
>> already said that I'd like to see text on:
>> - bleaching and middlebox requirements to deploy.
>> - Need to verify the paths actually really *do support* ECN (sorry, but
>> may be needed).
>
> I agree that verifying that a path can take a congestion notification e2e
> is important.
>
>>> I don't think this will be a quick (6 months) job, because of the
>>> problem of being clear about the "things like ECN" that it needs to
>>> talk
>>> about.
>>>
>> GF: That depends also in part on whether these new mechanisms:
>> will actually change the message
>> to potential users of transports and people considering deployment.
>>
>> In my mind the definition of the protocol techniques does not
>> HAVE to be the same document that tells people *HOW* to implement
>> this in stacks or network devices.
>> (My own choice would be to keep these to research
>> papers and RFCs targeted at their respective communities).
>>
>>>> > I don't share the relentless optimism of this document, and would
>>>> > like it - or a competing document - to go into the potential
>>>> negatives.
>>>>
>>>>    I think it should concentrate on what its name says: the benefits
>>>> of ECN, both now and in an expected future; but that it should also
>>>> at least mention downsides this WG sees: and that it should avoid any
>>>> recommendation stronger than "make ECN available to consenting
>>>> applications".
>>>
>>>
>>> I agree it should be informative, rather than making too many detailed
>>> recommendations.
>>>
>> GF: Any other bullets listing additional topics are most welcome!
>>
>>
>>>> > examples of this include the TOS washing problem bob alluded to
>>>> > in one of the tsvwg meetings (the monday one),
>>>>
>>>>    This definitely deserves mention.
>>>
>>>
>>> I agree it would be useful to write about deployment problems.
>>> Specifically, a clear explanation of what the deployment problems have
>>> been, which ones are no longer problems (if any), and which ones are
>>> still problems, and how prevalent.
>>>
>> GF: +1
>
> +1
>
>>> Alternatively, folks doing ECN black hole experiments might
>>> want to write them up in a separate draft, that this one can
>>> refer to (there are already a few research
>>> papers documenting ECN deployment experiments).  I would be
>>> willing to help collect together the history that I have on
>>> this.
>>>
>> GF: I'm doing these experiments too, happy to work with others.
>
> I have a couple tools for testing bursty loss and QoS and ecn e2e under
> development, they are a little buggy, and all dependent on more
> recent linux kernels (amusingingly IPv6 works better than IPv4 until
> very recently),  and could be improved.
>
> are there other tools available (scamper?)
>
>>>> > the impact on competing flows,
>>>>
>>>>    That might have to go into a companion document. I think this
>>>> document could try to describe the bounds of such issues, but not
>>>> the details.
>>>
>>> +1
>>>
>> GF: +1, I see this as informing the Engineering, not the goals of this
>> document.
>>
>>>> > the problem of unresponsive agents or other misuse,
>>>>
>>>>    I'm not sure what Dave is alluding to here...
>>>
>>> Dave is alluding to suppression of ECN in the feedback loop
>>> (e.g. by the receiver) or the
>>> sender not responding (the problem space that ConEx and
>>> the ECN Nonce target).
>>>
>> GF: I'd be glad to include something on this (not detailing a,
>> mechanism but perhaps linked to
>> "how do we know the path supports ECN", and perhaps if
>> the
>> group is smart - how can the transport actually find this stuff out for
>> itself? (sorry to keep returning to this)
>
> For TCP it seems rather hard to fix in the field. I could
> see supplying the syn/ack with a CE as
> one example. Newer protocols (quic/nada?) could
> do something more robust and periodically probe...
>
>>>> > the deprecation (?) of the nonce mechanism,
>>>>
>>>>I don't accept it as a given that the nonce should be deprecated;
>>>> though I do think that discussion will come up.
>>>
>>> It would also be useful to write about cheating problems.
>>>
>> GF: +1
>>
>>
>>> However, an informational doc would not be the right place to deprecate
>>> the ECN nonce. That needs to be in a doc that offers an alternative
>>> mechanism (which is where draft-moncaster-tcpm-rcv-cheat is heading -
>>> we have ideas on how to extend it to ECN cheating).
>>>
>> GF: - I'd be surprised if this document deprecates an EXP RFC (I've said
>> this before), normally I'd expect this in the draft that defines the
>> replacement technique.
>>
>>>
>>>> > and how to properly switch between marking and dropping in an aqm.
>>>>
>>>>    I doubt this document will go into much detail there. Basically,
>>>> IMHO, an AQM should mark well before dropping becomes necessary; and
>>>> when dropping becomes necessary, ECN-capable packets should be dropped
>>>> essentially as often as non-ECN-capable packets.
>>>>
>>>>    I'm not sure this document should say much about that, though...
>>>
>>>
>>> This might be relevant if talking about how there could be benefits if
>>> it were done differently from RFC3168. But otherwise, I agree this
>>> would
>>> not be on-topic for this doc.
>>>
>> GF: This could be complicated, but probably depends on how
>> far the WG has proceeded in other
>> documents when this document is ready to publish?
>>
>>>> > There are also the possibilities in new uses for ecn
>>>>  (for example, in the original rmcat
>>>> > nada proposal), in usages on local links in routing
>>>> > protocols, and in new protocols such as quic, etc.
>>>>
>>>>    Sounds like interesting reading, Dave -- do you want to send
>>>> pointers?
>>>
>>> <http://tools.ietf.org/html/draft-zhu-rmcat-nada-03>
>
> I like the idea of protecting the main frame (P-frame?
> can never keep these
> straight) with ecn, and allowing for loss on the deltas lacking ecn.
>
> Also don't mind the idea of protecting all of a videoconferencing session
> with ecn, and reacting to those congestion notifications appropriately.
> (assuming that the other problems involving washing, etc, are licked)
>
>>> I assume using ECN on local links in routing protocols is just
>>> something
>>> Dave is saying that operators could do unilaterally.
>
> A long running research project of mine (over 15 years running)
> has been to find a routing protocol
> that worked well for wireless, and one more holy grail
> has been to find one that reacted well to congestion and differences in
> available bandwidth. Most routing protocols
> stop at "reachability", and some conflate packet loss with that.
>
> and: ecn marking bgp tcp sessions would be a good way of making sure ecn
> worked right in the core. ;/
>
> Please note that although I think I've got tantalizing hints towards
> coming up with better routing metrics for wireless or congested
> networks as an outgrowth of the bufferbloat work (examples - the new
> babel-rtt metric, some improvements on minstrel algorithm's in-kernel
> connectivity and bandwidth reporting, and the idea of throwing a
> dropped or  marked packet up to user space where a routing daemon
> might take a look at it and  it's path and do something smarter about
> it) - I've been at it for a long time without much success and don't
> want to hold up more productive research elsewhere.
>
>> GF: The IETF has acknowledged alternate ECN semantics via setting the
>> DSCP  field (RFC4774, I recall some historical discussion of why
>> and where), at least something
>> could be said about this. I'd like to add at least a pointer.
>>
>>> Given QUIC includes FEC to hide losses, I guess it is a good example to
>>> consider whether ECN still offers sufficient benefits over and above
>>> just removing losses.
>>>
>> GF: And then, isn't the implication of AQM to significantly increase the
>> number of "losses" unless we use ECN?
>
GF: I replied in another thread - what I wrote wasn't what I intended to say.

> I routinely run two wired networks with fq_codel with nearly zero loss
> using ecn marking. I am curious as to the mark/drop statistics from
> other networks that have deployed ecn.
>
>> Indeed, I have the impression we are confusing many on
>> these points - ECN
>> could change the reaction to congestion signal, and FEC
>> (even opportunistic CC-friendly FEC)
>> can also change the way things react to congestion signals.
>
> I'd like to see more hard results from FEC from quic. I'd also love to
> see someone trying ECN with bittorrent traffic,
> adding it to an existing uTP client like utorrent or transmission
> would be straightforward, and an easy way to experiment with ecn from
> userspace, and explore the issues with deploying it outside of TCP.
>
>>> Cheers
>>>
>>> Bob
>>>
>>>> --
>>>> John Leslie <[e-mail]>
>>>>
>>>> _______________________________________________
>>>> aqm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/aqm
>>>
>>> ________________________________________________________________
>>> Bob Briscoe,                                                  BT
>>> _______________________________________________
>>> aqm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/aqm
>>
>> Gorry
>>
>> P.S. My proposal is that if this thread converges I intend to
>> parse a later version and see if my co-author
>> and I can then add some comments to our draft
>> to catalogue a set of issues that we expect to see added in
>> future, and an appendix of those we think may be out of scope.
>>
>> _______________________________________________
>> aqm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/aqm
>
> --
> Dave Täht
>
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>

So, back to this specific draft.

We (the authors) have already stated that we think this particular draft
should not recommend a specific way of using ECN  and we therefore do not
expect the next version will conclude that "some specific version should
be turned on", but we do expect to more clearly state that ECN marking
should not be violated, i.e. routers / middleboxes shouldn't delete the
codepoint and servers should respond.

Gorry