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 <[email protected]> wrote:
> On Mon, Aug 11, 2014 at 7:48 AM, Wesley Eddy <[email protected]> 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 <[email protected]>
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
