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.) > 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"). > 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. > 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". > 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. 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. 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. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
