Re: [tcpm] Review of draft-ietf-tcpm-generalized-ecn-04

["Scharf, Michael" <[e-mail]>]

Hi Marcelo,

Thanks for the reply and sorry for the delay; I was not in office.

I agree that the document has improved a lot. At first sight most of my concerns are addressed, albeit I suggest that others in the working group should carefully review the latest changes. More inline...

[...]

> > * Section 3.2
> >
> >    "It can be seen that the sender cannot set ECT on the SYN if it is not
> >    requesting AccECN feedback."
> >
> >   As mentioned before, I think this is one of the cases in which reasoning is
> needed as it is not trivial to understand the root cause. A reference to a later
> section could work.
> 
> 
> So, the reason why we (as WG) decided against supporting ECN marking
> of the SYN packets when AccECN is not supported is to prevent the
> consumption of reserved bits in the TCP header for  this purpose.
> 
> I mean, as currently defined, we need to be able to identify 3 types
> of servers, namely, non-ECN servers, classic ECN servers and AccECN
> servers (which already defined the encoding of the CE mark in the SYN
> packet).

I could think of a forth type of server, but I guess that question depends on the current discussions in TSVWG. So maybe I'll just await the outcome.

> If we were to also support classic ECN servers that support ECN++,
> this would be a new type of server that would then require an
> additional codepoint in the TCP header. We deemed this was wasteful
> (considering that there are very few bits reserved available) and
> especially considering that when we asked the WG (in several
> occasions) no-one expressed any interest in the support of a classic
> ECN server that supported ECN++.

I agree that there has not been much implementer interest in ECT in SYNs for RFC3168 ECN servers, and so I'll not further insist in such a use case.

I don't understand how ECT in SYNs would work if different ECN feedback mechanisms also existed, but maybe it is too early to ask that question, as it depends on TSVWG.

> In any case, we changed the text as follows:
> 
> s/   It can be seen that the sender cannot set ECT on the SYN if it is not
>    requesting AccECN feedback.
>  /  t can be seen that we recommend against the sender setting ECT on
>         the SYN if it is not requesting AccECN feedback.
>  /

Thanks for the more careful wording. I think it is up to the rest of the working group to carefully check whether this works for all use cases.

[...]

> > * Section 3.2
> >
> >   "Therefore it is RECOMMENDED that the
> >    experimental AccECN specification [I-D.ietf-tcpm-accurate-ecn] is
> >    implemented (as well as the present specification)"
> >
> >   I have repeatedly mentioned the downsides of creating dependencies
> between documents. In this case, the risk is that the AccECN experiment fails
> (e.g., the IETF has to obsolete it in some years because another alternative has
> been found). The same applies if a standards-track RFC of AccECN would not be
> backward-compatible for whatever reason. His would be a pity since significant
> parts of the document are entirely independent of AccECN. This risk could be
> reduced by not mandating a particular specification, but mandating functional
> requirements.
> >
> >   For instance, I believe that ECT on SYNs can always be set if there is a
> mechanism that reliably echos CE marks on SYNs back to the sender. AccECN is
> a solution to this, and the only solution we currently have, but we are dealing
> with experiments, not standards, so who knows what will happen in some years
> from now? To me, a better wording would be along the lines of (neglecting the
> previously mentioned exception): "ECT on SYNs can only be set if there is a
> corresponding feedback scheme. The experimental AccECN specification [I-
> D.ietf-tcpm-accurate-ecn] provides this feedback. It is RECOMMENDED to
> implement an accurate feedback scheme as well as the present specification." I
> merely show this as an example that would not be impossible to better
> decouple documents. As long as I am the only person who brings up this point, I
> don't ask for this specific change to be implemented. I just like to record my
> concern including potential solutions (e.g., for a document shepherd).
> >
> 
> I agree with this approach.
> 
> I have modified the document in several parts to provide guidance
> about how to enable ECN++ in future ECN feedback mechanisms to be
> defined. However, as of today, there are only two ECN feedback
> mechanisms for TCP defined, standard ECN and AccECN. We have also been
> asked to ensure this draft is concrete and clear, so we want to
> describe in detail what ECN++ should do in both cases as the document
> does. So, my proposal is to 1) keep all the guidance and
> reccomendations regarding legacy ECN and AccECN feedback and 2)
> provide guidance on the ECN++ support for future ECN feedback
> mechanisms, based on the funcitonality required, as you suggest.
> 
> To achieve that I have modified the following subsections:
> 
> In the Introduction, I have included:
> 
>       <t>ECN++ uses a sender-only deployment model. It works whether the two
>       ends of the TCP connection use classic ECN feedback <xref
>       target="RFC3168"/> or experimental Accurate ECN feedback (AccECN <xref
>       target="I-D.ietf-tcpm-accurate-ecn"/>), the only two ECN feedback
>       mechanisms for TCP standardised at the time of this writing.

The correct term for an experimental protocol would be "specified" instead of "standardised". So, at minimum, it must be changed if the protocol shall be experimental.

I would personally recommend to remove the part after the comma as this creates yet another dependency on the outcome of IETF discussions. If the sentence stays, it will need to be verified later. 
 
>       Nonetheless, if the client does
>       not implement AccECN, it cannot use ECN++ the initial SYN packet.
>       Using ECN in the SYN packets provides significant benefits, as we describe
>       in the next subsection. However, unlike RFC 3168 feedback, AccECN
> provides
>       a way for a TCP server to feed back whether a SYN arrived marked CE. So,
>       if the client does not implement AccECN, it could be unsafe to use ECN++
>       on the initial SYN packet. Therefore, implementers of ECN++
>       are RECOMMENDED to also implement AccECN. In this document, we also
>       provide guidance regarding the ECN++ support for future
>       ECN feedback mechanisms for TCP based on the the functionality required
>       to enable ECN marking of the different packets.</t>
> 
> Then in section 3.2 I modified the following paragraph as follows:
> 
>         <t>Nonetheless, this specification also caters for the case where an
>         ECN++ TCP sender is not using AccECN. This could be because it does
>         not support AccECN or because the other end of the TCP connection does
>         not (AccECN can only be used for a connection if both ends support
>         it). </t>
> Also, section 3.2.1.1. was modified as follows:
> 
>             <t>With classic <xref target="RFC3168"/> ECN feedback, the SYN was
>             not expected to be ECN-capable, so the flag provided to feed back
>             congestion was put to another use (it is used in combination with
>             other flags to indicate that the responder supports ECN). In
>             contrast, Accurate ECN (AccECN) feedback <xref
>             target="I-D.ietf-tcpm-accurate-ecn"/> provides a codepoint in the
>             SYN-ACK for the responder to feed back whether the SYN arrived
>             marked CE. Therefore the setting of the IP/ECN field on the SYN is
>             specified separately for each case in the following two
>             subsections. If in the future, additional ECN feedback
> mechanisms are
>             defined for TCP, it would only be possible to enable the ECT marking
>             of the SYN packets as long as the new ECN feedback
> mechanism provides
>             the means to feed back the CE marking of the SYN back to the TCP
>             initiator. If this is the case, the new ECN feedback
> mechanism should
>             follow the same recommendation described below for AccECN
> regarding
>             the processing of the SYN packets.</t>

Currently I don't know if such new ECN feedback mechanisms will exist soon-ish in the IETF. If not, the wording would probably work for me.

[...]

> > * Section 5.1.  IW10
> >
> >   "As specified in Section 3.2.1.1, a TCP initiator can only set ECT on
> >    the SYN if it requests AccECN support.  If, however, the SYN-ACK
> >    tells the initiator that the responder does not support AccECN,
> >    Section 3.2.1.1 advises the initiator to conservatively reduce its
> >    initial window to 1 SMSS because, if the SYN was CE-marked, the SYN-
> >    ACK has no way to feed that back.
> >
> >    If the initiator implements IW10, it seems rather over-conservative
> >    to reduce IW from 10 to 1 just in case a congestion marking was
> >    missed.  Nonetheless, the reduction to 1 SMSS will rarely harm
> >    performance, because:
> >
> >    o  as long as the initiator is caching failures to negotiate AccECN,
> >       subsequent attempts to access the same server will not use ECT on
> >       the SYN anyway, so there will no longer be any need to
> >       conservatively reduce IW;
> >
> >    o  currently, at least for web sessions, it is extremely rare for a
> >       TCP initiator (client) to have more than one data segment to send
> >       at the start of a TCP connection [28; Fig 3] - IW10 is primarily
> >       exploited by TCP servers."
> >
> >   See my previous questions. I do not understand why there is no deployed
> TCP-based application with some reasonable share of traffic that sends more
> than one segment at the beginning of the TCP connection. This document deals
> with all TCP usage; it is not written only for the communication between Web
> browsers and Web servers. For instance, why would the TCP client in an FTP
> session not use IW10? I disagree that one can generalize from HTTP to all TCP-
> based application protocols. And there is also no evidence that caching will
> work for any TCP protocol. For that, the worst-case scenario would be end-
> systems that maintain TCP connections to _many_ peers (at least tens of
> thousands of peers, maybe even more). How well will caching work in such
> cases? If those statements are not backed better, the text already explains what
> a reader could conclude: "it seems rather over-conservative to reduce IW from
> 10 to 1 just in case a congestion marking was missed." Yes, indeed, unless
> proven otherwise.
> 
> 
> 
> There are several aspects to this comment:
> First, section 3.3.1.3 recommends to reduce the IW to 1 MSS, but it
> allows for the initiator to use a greater window. So, an implementer
> can decide whether to follow the recommendation or not.
> 
> This section serves the purpose of informing the implementors when
> deciding whether they will follow the recommendation or not. I believe
> that it is useful for them to provide information about the impact in
> web traffic, as it does account for a large set of the traffic. If the
> implementaros have a different applications use case in mind, she
> shouldnt take this into account. Similarly for caching. Keep in mind
> that caching is relevant in clients. I would assume that a very large
> majority of clients would work well with a smaller cache than your
> worst case. If an implementor expects that several tens of thousands
> of outgoing connections will be the usual case, she should not
> consider this argument neither. Again, this is a non normative part of
> the specification. Keeping these arguments here, allow the
> implementors to not follow the recommendation if the arguments here
> are not convincing.

As I am not an implementer, it probably does not make sense to further push back here.

Yet, I suggest that implementers carefully review this section as this is also a lot about stack internals. I think it would be good to have a confirmation that the new wording works for implementers.

> > * Section 2
> >
> >   "Optionally, it could mean ECT(1), which is in the process of being redefined
> for use by L4S experiments [RFC8311] [I-D.ietf-tsvwg-ecn-l4s-id]."
> >
> >   I don't understand why this matters here given that section 1 already
> explains that this document is compatible with L4S.
> 
> 
> 
> but it makes sense to mention it here, since we provide some
> justification why by default is ECt(0) and what about ECT(1).

I believe that "Optionally, it could mean ECT(1)" would be sufficient, as then the document would get independent of ongoing discussions. Anyway, this statement should probably be reviewed after the ongoing discussions have reached consensus.

[...]

One additional comment on the Security Considerations, which is a bit short:

Could ECN++ be used for improving TCP/IP stack fingerprinting? Specifically the SYN may be of interest for that. If so, it may be worthwhile to mention this in the Security Considerations.

If so, this actually could also matter for the Security Consideration section in draft-ietf-tcpm-accurate-ecn.


Editorial nits:

- page 9: "does not support__ AccECN"

- page 11: "does not support AccECN a_n_d if the initial congestion"


Thanks again

Michael