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

[Gorry Fairhurst <[e-mail]>]

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

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

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

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

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.

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