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 <[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.
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 <[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
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
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
