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

[Bob Briscoe <[e-mail]>]

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? 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).

How about the title "Explicit Congestion Notification (ECN): 
Benefits, Opportunities and Pitfalls" ?

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

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.


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


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

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.


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


> > 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).


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

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).


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


> > 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 assume using ECN on local links in routing protocols is just 
something Dave is saying that operators could do unilaterally.

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.

Cheers


Bob


>--
>John Leslie <[e-mail]>
>
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT