Re: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn

[Bob Briscoe <[e-mail]>]

Yuchung,

On 13/07/18 21:45, Yuchung Cheng wrote:
> On Fri, Jul 13, 2018 at 12:42 PM, Mirja Kühlewind
> <[e-mail]> wrote:
>> Hi Yuchung,
>>
>>> Am 13.07.2018 um 15:30 schrieb Yuchung Cheng <[e-mail]>:
>>>
>>> On Fri, Jul 13, 2018 at 11:53 AM, Mirja Kühlewind
>>> <[e-mail]> wrote:
>>>> Hi Yucheng,
>>>>
>>>> please see below.
>>>>
>>>>> Am 13.07.2018 um 14:38 schrieb Yuchung Cheng <[e-mail]>:
>>>>>
>>>>> hi --
>>>>>
>>>>> I agree:
>>>>> 1. delayed/streched ACK aren't going away (in fact will be more common)
>>>>> 2. GRO isn't and should not be a show-stopper
>>>>> 3. SYN option is running tight
>>>>> 4. HW opt comes after SW
>>>>>
>>>>> I worry:
>>>>> 1. GRO is a unavoidable issue in deployment (let's not produce an
>>>>> undeployable RFC). the ACE counter won't work as GRO can pack up to
>>>>> 64KB/MTU =~ 45 pkts under heavy congestion.
[BB] I'm really not expert on offload, but I thought GRO collects (or 
can be made to collect) a set of fields from the headers it strips off?

If I'm wrong (quite likely), bear in mind the following:
* you only need the ACE counter (main header) when the AccECN Option is 
being stripped by a middlebox
* on those connections that need ACE (cos of middlebox meddling) 
couldn't GRO be limited to 8 packets, at least while experimenting with 
AccECN to see if it is useful and gather data?

* Appendix A.2. Example Algorithm for Safety Against Long Sequences of 
ACK Loss 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-A.2> 
is not just for ACK losses. It would be just as useful if GRO 'lost' the 
headers. It uses the TCP acknowledgement number and any SACK options to 
check whether the ACE field could have wrapped, and if so by how much.


>>>>> 4. If SYN option space is a concern, ACE header exchange is ok. But I
>>>>> suspect the latter has more middlebox issue based on my TFO deployment
>>>>> experience.
You may remember earlier in TCPM, Marcelo presented the measurement 
study we did. Altho it was titled as primarily about ECN++ traversal (IP 
header), it also did a lot more limited measurements of traversal of the 
ECN flags (main TCP header).

The paper summarizing the results is here, as well as the dataset:
     http://www.it.uc3m.es/amandala/ecn++/

It covered 6.5 million different paths over 20 mobile networks in 8 
European countries as well as over 50 fixed networks globally. I know 
that's diddly-squat compared to what Google can do, but the data is 
still worth a lot.

However, the data we got on traversal of the TCP header was much more 
limited. We controlled all our client vantage points, but only a few 
servers, with the bulk of the servers being the Alexa 500k. Where we 
didn't control the server, we could only rely on using tracebox which 
checks ICMP TTL exceeded messages against what was sent. But few routers 
implement the updated ICMP [RFC1812] that includes more of the transport 
header than the first 8B.

FWIW, we didn't find any mangling of the ECN TCP header flags.


>>>>>
>>>>>
>>>>> So with all that said, is it possible to have a "minimal"-ACE that
>>>>> 1. Does ACE handshake as proposed
>>>>>
>>>>>
[snip #2 about ECN++]
>>>>> 3. Leave ACE-count and ACE option optional (i.e. MAY)
>>>> I don’t understand this. If both is optional, you don’t have any feedback. Or what do you mean by „leave ACE-count optional“?
>>> use-case: We can negotiate DCTCP-style ECN for the internet.
>>>
>>> Then interested parties can progressively experiment on more accurate
>>> "options" (!= TCP-option)
I must point out that there is very limited space and flexibility for 
versioning experiments with multiple variants of how the 3 'ECN' flags 
in the main header are used. You will see from the latest appendix B 
(added in response to Michael Scharf's point on this) that there is no 
more space for further negotiation on the SYN or SYN/ACK, but there are 
5 unused codepoints on the final ACK of the 3WHS and 7 on the first data 
packet. Ideally the negotiation would be on the SYN and SYN/ACK though, 
especially if used in combination with TFO.

This means you will need to be much more certain about whether there 
really are GRO problems, or just maybe. And if so, we're going to have 
to try to work out a solution on paper first (or at least on private 
networks), rather than burning bits by trial and error.

This also means going into the depths of the draft in full (if you 
haven't already done so), cos the co-authors did go thru a huge number 
of possible designs ourselves over the years, and we fixed all sorts of 
potential problems in the process.

Put another way, if you start from scratch, you will be finding new 
problems to solve for a year or so after you start.


BTW, there is a lot more scope for versioning multiple variants of 
AccECN TCP options.

>> As Appendix A of RFC7560 says I don’t think it is a safe option for the Internet where packet loss more likely then in a full ECN-enabled data center.
> Again I disagree RFC7560 Appendix A is a big problem based on my
> experience with at times loss-heavy ECN-enabled data-center (Google
> data-center runs very hot and uses a DCTCP-variant).
To be clear, you're only disagreeing that packet loss is not a 
non-problem in DCs (excuse the double negative). You're not disagreeing 
that packet loss is a problem for DCTCP feedback.

Cheers



Bob
>
> We can quabble forever w/o data. That's why I asked for some
> (non-simulation) data.
>
>> Mirja
>>
>>
>>
>>>> Mirja
>>>>
>>>>
>>>>
>>>>> as a "fairly safe" to deployment compromise. And I am happy to draft a
>>>>> kernel patch for that :-)
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 13, 2018 at 1:18 AM, Bob Briscoe <[e-mail]> wrote:
>>>>>> Yuchung,
>>>>>>
>>>>>> On 12/07/18 17:03, Mirja Kühlewind wrote:
>>>>>>> Hi Yuchung,
>>>>>>>
>>>>>>> please see below.
>>>>>>>
>>>>>>>> Am 12.07.2018 um 11:41 schrieb Yuchung Cheng <[e-mail]>:
>>>>>>>>
>>>>>>>> Yes packets with ACE options and (different) ACE-counter header would
>>>>>>>> break GRO. There're many legacy h/w and s/w.
>>>>>>> I’m not the expert here but my understanding is that is would not break
>>>>>>> GRO but could not make actual use or it if the ACE counter changed or the
>>>>>>> option is present.
>>>>>> [BB] Yuchung's criticism applies to any scheme that feeds back a continually
>>>>>> changing signal like ECN. For instance, like AccECN feedback, DCTCP ECN
>>>>>> feedback continually changes the TCP header flags, and I believe DCTCP is
>>>>>> widely used in DCs.
>>>>>>
>>>>>> I believe, to make GRO support ECN feedback (whether DCTCP or AccECN), it
>>>>>> would be necessary for GRO to know which bits to mask when determining
>>>>>> whether a packet is mergeable with others. I believe GRO already collects
>>>>>> header fields separately for the TCP logic to be able to work on them, but
>>>>>> I'm also not an expert.
>>>>>>> However, usually your will only have a small number of CE marks every
>>>>>>> couple of RTTs, and the counter only changes if you CE marks/the option is
>>>>>>> only present a few times per RTT. So the impact should be rather low. But
>>>>>>> this clear something to evaluate for the experiment.
>>>>>> [BB] With DCTCP as currently designed, you tend to get runs of 100% CE if
>>>>>> the load of short flows is very small. In that case, DCTCP feedback will
>>>>>> change the header flags less often than AccECN. However, with more short
>>>>>> flows, the feedback is more on-off. Then the flags change more often with
>>>>>> DCTCP than with AccECN feedback.
>>>>>>
>>>>>> In general, hardware optimization is not going to optimize a protocol that
>>>>>> didn't exist when the hardware was designed. It would be ideal to design a
>>>>>> new protocol that takes advantage of existing hardware optimization.
>>>>>> However, as long as an experimental protocol still works with existing
>>>>>> hardware, I think it's reasonable to assume that hardware optimization will
>>>>>> only arrive once a protocol has become well-established.
>>>>>>
>>>>>>>> Even without option, ACE header only allows reflecting up to 8 packets
>>>>>>>> for receiver segmentation offload and ACK suppression?
>>>>>>> Same as above, it can only up to 8 CE marked packets per ACK, however, CE
>>>>>>> marking rater are expected to be rather low. ACK suppression should probably
>>>>>>> not be used if the ACE counter has changes, however, usually the ACE counter
>>>>>>> stays stable for multiple RTTs and then ACK suppression is not a problem.
>>>>>>> However, not sure I understood you question here correctly…?
>>>>>>>
>>>>>>>> The appendix on ack loss causes ambiguity is good: but the pattern
>>>>>>>> drops specifically the state-switch (CE<->noCE) ACK which only happens
>>>>>>>> on delayed ACK. Is that pattern common? - or can we address most of
>>>>>>>> that by delaying less ACKs?
>>>>>>> I guess you have a 50% chance today to hit a delayed ACK. I guess delaying
>>>>>>> less (where you delay every second ACK today) would mean ACK every packet,
>>>>>>> and thus double ACK load on the network. I guess on today networks that
>>>>>>> actually in most cases not a problem, however, there might be specially
>>>>>>> cases where it is. However, that’s problem an independent question to
>>>>>>> evaluate.
>>>>>> [BB] If there were no delayed ACKs, the problem with DCTCP feedback would
>>>>>> largely disappear. But delayed ACKs are not going away. Which is why we
>>>>>> proposed replacing DCTCP feedback with AccECN feedback.
>>>>>>>
>>>>>>>> I am all for making ECN more accurate for wide area beyond DCTCP, but
>>>>>>>> am evaluating the pros/cons. What if we just
>>>>>>>> 1. negotiate 'better' ECN via new SYN option
>>>>>>> Not sure I understand your proposal correctly, but I assume you mean
>>>>>>> negotiate via SYN option and then just use the ACE counter in the header? If
>>>>>>> so, I don’t understand why you see the negotiation part in the TCP header as
>>>>>>> the problem?
>>>>>> [BB] @Yuchung, as Mirja says, your point #1 seems to be proposing a solution
>>>>>> without a problem. In fact an option on the SYN would create a new problem
>>>>>> 'cos of the severe shortage of space for SYN options (for this reason, the
>>>>>> AccECN TCP option was designed not to be needed on the SYN).
>>>>>>>
>>>>>>>> 2. mark all packets like ECN++
>>>>>>> That would be nice but here you actually need AccECN because you want to
>>>>>>> have feedback for control packets as well. AccECN is providing this
>>>>>>> feedback. AccECN does not change the „use of ECN“; that’s what we have ECN++
>>>>>>> for; both thing ideally would be deployed together however. Was that your
>>>>>>> questions?
>>>>>> Cheers
>>>>>>
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>>> Mirja
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jul 12, 2018 at 3:23 AM, Mirja Kühlewind
>>>>>>>> <[e-mail]> wrote:
>>>>>>>>> Hi Yuchung,
>>>>>>>>>
>>>>>>>>> the question if you need this „more“ on accuracy really depends on the
>>>>>>>>> use case. If you use DCTCP as today, the ACE counter in the TCP is probably
>>>>>>>>> sufficient and you might not want to pay the additional overhead in your
>>>>>>>>> data center (that why the option is actually optional).
>>>>>>>>>
>>>>>>>>> If you however, e.g., have very differently sized packets, then the byte
>>>>>>>>> counter in the option could give you a more accurate signal. Or if you are
>>>>>>>>> also interested in the ECT(1) counter, you need the option. Further the ACE
>>>>>>>>> counter also give your feedback on control packet and the option enables you
>>>>>>>>> to distinguish between CE-amrked payload and control packets, which can also
>>>>>>>>> become important when experimenting with making all packets ECN-capable.
>>>>>>>>>
>>>>>>>>> Given accECN is a general feedback mechanism that in fact is designed to
>>>>>>>>> enable new future uses of the ECN signal, we wanted to keep all these option
>>>>>>>>> available while making is still as simple as possible and as flexible as
>>>>>>>>> possible.
>>>>>>>>>
>>>>>>>>> Mirja
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Am 11.07.2018 um 14:35 schrieb Yuchung Cheng <[e-mail]>:
>>>>>>>>>>
>>>>>>>>>> Hi Bob,
>>>>>>>>>>
>>>>>>>>>> Neal and I evaluated the earlier draft. It is well-thought out but
>>>>>>>>>> we're concerned about the options. Option is not mandatory but the
>>>>>>>>>> lack of it also reduces accuracy. Option runs into space issues w/
>>>>>>>>>> SACK and offload issues w/ TSO/GRO. They can be addressed for sure but
>>>>>>>>>> aren't easy.
>>>>>>>>>>
>>>>>>>>>> We're curious how much more "accuracy" it buys over current
>>>>>>>>>> DCTCP-style ECN. Is there any study to show trade-offs of
>>>>>>>>>> full-ACE-w-options vs ACE-wo-options vs current DCTCP-ECN?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Jul 11, 2018 at 11:00 AM, Bob Briscoe <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>>> Michael, tcpm list,
>>>>>>>>>>>
>>>>>>>>>>> As well as addressing your points, as Mirja has already mentioned
>>>>>>>>>>> below, we
>>>>>>>>>>> added a whole new appendix giving the rationale for the bits and
>>>>>>>>>>> codepoints
>>>>>>>>>>> that AccECN has proposed to use on 1) the SYN and 2) SYN/ACK. A 3rd
>>>>>>>>>>> subsection also identifies space for future evolution. It also points
>>>>>>>>>>> to
>>>>>>>>>>> where rationale was already given in the body of the draft.
>>>>>>>>>>>
>>>>>>>>>>> The appendix is in the draft submitted last week, available here:
>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#appendix-B
>>>>>>>>>>>
>>>>>>>>>>> We'd be interested to hear whether this allays your concerns.
>>>>>>>>>>>
>>>>>>>>>>> We have asked to present this in Montreal as well.
>>>>>>>>>>>
>>>>>>>>>>> Cheers
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Bob
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 02/07/18 16:54, Mirja Kühlewind wrote:
>>>>>>>>>>>> Hi Micheal,
>>>>>>>>>>>>
>>>>>>>>>>>> I addressed a couple of your comments below.
>>>>>>>>>>>>
>>>>>>>>>>>> For the other, bigger comments regarding extensibility, that I did
>>>>>>>>>>>> not yet
>>>>>>>>>>>> address below, we plan to add a new section to the appendix to
>>>>>>>>>>>> explain
>>>>>>>>>>>> extensibility options as previously discussed by mail. We will
>>>>>>>>>>>> probably send
>>>>>>>>>>>> a separate email on that part.
>>>>>>>>>>>>
>>>>>>>>>>>> Mirja
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Am 12.03.2018 um 01:59 schrieb Scharf, Michael (Nokia -
>>>>>>>>>>>>> DE/Stuttgart)
>>>>>>>>>>>>> <[e-mail]>:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Mirja,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks a lot for the explanation. I won't follow-up on some of the
>>>>>>>>>>>>> editorial suggestions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yet, I continue to believe that some formal wording in the document
>>>>>>>>>>>>> needs
>>>>>>>>>>>>> to change, as explained below.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>
>>>>>>>>>>>>> Michael (with no hat on)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Mirja Kühlewind [mailto:[e-mail]]
>>>>>>>>>>>>>> Sent: Monday, March 05, 2018 1:54 PM
>>>>>>>>>>>>>> To: Scharf, Michael (Nokia - DE/Stuttgart)
>>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>>> Cc: [e-mail]; [e-mail]
>>>>>>>>>>>>>> Subject: Re: Comments on draft-ietf-tcpm-accurate-ecn
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Micheal,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks for your feedback and sorry for my late reply.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please see inline.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 03.12.2017 um 20:17 schrieb Scharf, Michael (Nokia -
>>>>>>>>>>>>>>> DE/Stuttgart)
>>>>>>>>>>>>>> <[e-mail]>:
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have read draft-ietf-tcpm-accurate-ecn-05 (without the
>>>>>>>>>>>>>>> appendix). I
>>>>>>>>>>>>>> believe this document needs further work before moving forward.
>>>>>>>>>>>>>>> Please find below my comments marked as [ms]. I have read the
>>>>>>>>>>>>>> document independent of the review from Gorry. I apologize if there
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> duplication.
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Michael (with no hat on)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ******************************
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Abstract:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Recently, new TCP mechanisms like Congestion Exposure (ConEx) or
>>>>>>>>>>>>>>> Data
>>>>>>>>>>>>>> Center TCP
>>>>>>>>>>>>>>> (DCTCP) need more accurate ECN feedback information whenever
>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>> than one marking is received in one RTT.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ms] I don't think this statement is fully backed by RFC 8257. I
>>>>>>>>>>>>>>> suggest to
>>>>>>>>>>>>>> remove this, or replace it by a more generic statement that more
>>>>>>>>>>>>>> accurate
>>>>>>>>>>>>>> information can be useful for several TCP extensions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I disagree. Both ConEx and DCTCP need more accurate information.
>>>>>>>>>>>>>> They do
>>>>>>>>>>>>>> not need the mechanism that is specified in this draft, however,
>>>>>>>>>>>>>> this is
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> what the sentences is saying.
>>>>>>>>>>>>> In my understanding (as a non-native speaker), the use of the word
>>>>>>>>>>>>> "need"
>>>>>>>>>>>>> is not correct here. DCTCP as specified in RFC 8257 can be
>>>>>>>>>>>>> implemented
>>>>>>>>>>>>> without any such mechanism.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What would work for me is something of the form "... Data Center TCP
>>>>>>>>>>>>> cannot get precise ECN feedback whenever more than one marking is
>>>>>>>>>>>>> received
>>>>>>>>>>>>> in one RTT“.
>>>>>>>>>>>> This is not correct. DCTP need more than one feedback signal per RTT
>>>>>>>>>>>> and
>>>>>>>>>>>> therefore cannot use RFC3168; instead it implement it’s own feedback
>>>>>>>>>>>> mechanism. However, to avoid confusion such that people could assume
>>>>>>>>>>>> DCTP
>>>>>>>>>>>> would not work without the accECN scheme as specified in this doc, I
>>>>>>>>>>>> rephrased to:
>>>>>>>>>>>>
>>>>>>>>>>>> "Recently, proposed
>>>>>>>>>>>>      mechanisms like Congestion Exposure (ConEx <xref
>>>>>>>>>>>> target="RFC7713"/>),
>>>>>>>>>>>>      DCTCP <xref target="RFC8257"/> or L4S <xref
>>>>>>>>>>>>      target="I-D.ietf-tsvwg-l4s-arch"/> need to know when more than
>>>>>>>>>>>> one
>>>>>>>>>>>>      marking is received in one RTT which is
>>>>>>>>>>>>      information that cannot be provided by the feedback scheme as
>>>>>>>>>>>> specified in
>>>>>>>>>>>>      <xref target="RFC3168"/>."
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>> This document specifies an
>>>>>>>>>>>>>>> experimental scheme to provide more than one feedback signal per
>>>>>>>>>>>>>>> RTT
>>>>>>>>>>>>>>> in the TCP header.  Given TCP header space is scarce, it
>>>>>>>>>>>>>>> overloads
>>>>>>>>>>>>>>> the three existing ECN-related flags in the TCP header and
>>>>>>>>>>>>>>> provides
>>>>>>>>>>>>>>> additional information in a new TCP option.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ms] This statement needs to be rewritten to correctly reflect
>>>>>>>>>>>>>>> what is
>>>>>>>>>>>>>> requested from IANA. My understanding is that this experimental
>>>>>>>>>>>>>> document
>>>>>>>>>>>>>> asks for allocation of a reserved TCP header flag. This needs to be
>>>>>>>>>>>>>> called out
>>>>>>>>>>>>>> prominently, IMHO. In addition, since this is not a standard, the
>>>>>>>>>>>>>> suggested
>>>>>>>>>>>>>> experimentation with the main TCP header must IMHO be explicitly
>>>>>>>>>>>>>> mentioned. I also suggest to have later in a document a section
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> explicitly
>>>>>>>>>>>>>> explains why it is appropriate to modify the main TCP header in an
>>>>>>>>>>>>>> experiment.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don’t know if any requirement that IANA assignment need to be
>>>>>>>>>>>>>> called
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>> in the abstract but we can do that. However, I believe the question
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> document should or should not assign the bit is still not
>>>>>>>>>>>>>> completely
>>>>>>>>>>>>>> solved, or
>>>>>>>>>>>>>> is it?
>>>>>>>>>>>>> I believe this question will have to be reviewed during WGLC and,
>>>>>>>>>>>>> more
>>>>>>>>>>>>> importantly, IETF last call. For the moment, my concern is that the
>>>>>>>>>>>>> document
>>>>>>>>>>>>> correctly describes the IANA allocation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to see here a statement such as : "Given TCP header
>>>>>>>>>>>>> space is
>>>>>>>>>>>>> scarce, this specification allocates a reserved header bit and
>>>>>>>>>>>>> overloads the
>>>>>>>>>>>>> two ECN flags in the TCP header ...“.
>>>>>>>>>>>> A bit lengthy but now:
>>>>>>>>>>>>
>>>>>>>>>>>> "Given TCP header space is
>>>>>>>>>>>>      scarce, it allocates a reserved header bit, that was previously
>>>>>>>>>>>> used for
>>>>>>>>>>>>      ECN-Nonce which was recently declared historic, and overloads
>>>>>>>>>>>> the
>>>>>>>>>>>>      two existing ECN flags in the TCP header. Further, additional
>>>>>>>>>>>>      information can be provided in a new TCP option that however is
>>>>>>>>>>>> not
>>>>>>>>>>>> used
>>>>>>>>>>>>      on the TCP SYN."
>>>>>>>>>>>>
>>>>>>>>>>>>>>> * 1.  Introduction
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Recently, proposed mechanisms like Congestion Exposure (ConEx
>>>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch]
>>>>>>>>>>>>>>> need
>>>>>>>>>>>>>>> more accurate ECN feedback information whenever more than one
>>>>>>>>>>>>>> marking
>>>>>>>>>>>>>>> is received in one RTT.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ms] At least for RFC 8257 seems to be implementable withoit this.
>>>>>>>>>>>>>>> Instead
>>>>>>>>>>>>>> of stating a "need", it would IMHO make more sense to discuss the
>>>>>>>>>>>>>> benefits
>>>>>>>>>>>>>> of the suggested mechanism in this document of its own, independent
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> other proposals. To me, this document should be independent of
>>>>>>>>>>>>>> other
>>>>>>>>>>>>>> documents and specifically other experiments. We have to think
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>> cases
>>>>>>>>>>>>>> where not all experiments are successful. Then independent
>>>>>>>>>>>>>> documents
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be more future-proof in future.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is a naming collision… The sentence was meant to say that
>>>>>>>>>>>>>> these
>>>>>>>>>>>>>> mechanisms new more accurate ECN feedback than provided today by
>>>>>>>>>>>>>> RFC3168 but it was not meant to say that these mechanism have to
>>>>>>>>>>>>>> use the
>>>>>>>>>>>>>> scheme as specified in this document.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I added the following part sentence:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> „Recently, proposed mechanisms like Congestion Exposure (ConEx
>>>>>>>>>>>>>> [RFC7713]), DCTCP [RFC8257] or L4S [I-D.ietf-tsvwg-l4s-arch] need
>>>>>>>>>>>>>> more
>>>>>>>>>>>>>> accurate ECN feedback information than provided by the feedback
>>>>>>>>>>>>>> scheme
>>>>>>>>>>>>>> as specified in [RFC3168] whenever more than one marking is
>>>>>>>>>>>>>> received in
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>> RTT. This document specifies an alternative feedback scheme that
>>>>>>>>>>>>>> provides
>>>>>>>>>>>>>> more accurate information and could be used by these new TCP
>>>>>>>>>>>>>> extensions.“
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does this help?
>>>>>>>>>>>>> See my proposal for the abstract. I continue to disagree with the
>>>>>>>>>>>>> term
>>>>>>>>>>>>> "need" but I think this can be sorted out by another term.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If AccECN progresses from experimental to the standards
>>>>>>>>>>>>>>> track, it is intended to be a complete replacement for classic
>>>>>>>>>>>>>>> TCP/
>>>>>>>>>>>>>>> ECN feedback, not a fork in the design of TCP.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [ms] This sentence should be removed, as this is speculation

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/