I have a few responses in-line: > Scheffenegger, Richard <[email protected]> wrote: >> [Michael Welzl <[email protected]> wrote:] >> >>> Do you know about any other disadvantages? > > While I believe discussion of disadvantages would help, I see a more > fundamental question: > > "What modifications/extensions to RFC 3168 are appropriate to achieve > the benefits being discussed?" > > (Of course, RFCs 4301 and 6040 discuss handling of ECN in tunnels; > this much extension is hopefully a given.) > That's a good topic - but that's surely one for tsvwg if you are suggesting a change to ECN.
>> I think the biggest issue is the interaction between ECN and non-ECN >> flows (and packets; > > I'm not quite sure what Richard means here -- there's an obvious > question about one starving the other (and I do think that's an issue, > but not quite a "disadvantage"). > I think maybe we are off-topic for the draft I was envisaging - which was "what are all the things that ECN can offer to applications". >> for TCP, only data segments are specified to optionally be ECN-enabled, >> not pure ACKs, and other control segments (some are allowed as >> experimental, i.e. SYN/ACK). > > This is an obvious area for improvement; but I really can't see it as > a "disadvantage" of ECN. > I'm lost here too about the issue, unless you mean that packets may be queued separately when ECN is enabled and this results in a flow being in multiple queues - is that what you mean? >> If ECN would have been seen as universally good (back in the day), >> it is odd that one L4 flow (TCP session) is constituted from both >> ECN- and non-ECN segments during it's lifetime. > > I don't see that as "odd" -- just "suboptimal". > Is this the same as above? >> The natural conclusion would be to assume that ECN on pure ACK, FIN, RST >> is detrimental in some way (personally I tend to disagree; there may not >> be any significant benefit, but it wouldn't break anything either - >> just the opposite, pure ACKs would serve as probes into the congestion >> state of the return path, once the data direction within the TCP flow >> reverses). > > Again, an obvious area for improvement... > >> But these points are transport specific; > > Exactly! It makes very little sense to blame "ECN" for these issues. > >> However, guidance to transport protocol designers on the use of ECN >> with control segments etc seems like it could be in scope for this >> document? > > I don't agree. > I think this is something that needs to be done when we update ECN - should tsvwg decide to do this - my hope was that this ID would be useful to people designing apps/networks - not transport protocol people. > The Abstract says: > " > " This document describes the potential benefits to applications when > " they enable Explicit Congestion Notification (ECN). > > which implies to me that it should discuss benefits regardless of the > particular transport protocol (and I think it does). > > The document describes setting the ECT(0) or ECT(1) codepoint in the > IP header and how routers may react to that. Not until Section 4 does > it mention particular transports; and IMHO those are listed strictly > as examples. > > I believe the document intentionally avoids questions about the > design of transport protocols; and I think it should continue to avoid > those. > OK - that's what we were thinking. > But the document _does_ mention several times the desirability of > ECN-marking packets which would not otherwise be dropped. > > I quite agree that is desirable; but it is a fundamental change to > RFC 3168; and I think we need to justify it considerably more than > this document does. This will not be a trivial change to deploy. > > It will indeed require deployment in routers and transport stacks, > but the question is quite independent of the transport _protocols_ -- > and I strongly suggest we don't confuse the two. > This probably lies in a different document - but that is not to say we shouldn't progress the two ideas in parallel if both are good. > -- > John Leslie <[email protected]> > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > Gorry _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
