Subject: Re: [tcpm] A possible simplification for AccECN servers

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 2 Dec 2019 12:15:18 +0100

Hi Bob,

Regarding the sentence:

"I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).”

This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead.

Mirja

> On 25. Nov 2019, at 22:41, Bob Briscoe <[email-masked]> wrote:
> 
> Mirja,
> 
> 
> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
>> Hi Jonathan,
>> 
>> Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me.
>> 
>> Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.
> In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol.
> 
> This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!).
> 
> The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes.
> 
> In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.
> 
> The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN.
> 
> I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).
> 
> It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.
> 
> 
> 
> Bob
>> 
>> Mirja
>> 
>> 
>>> On 25. Nov 2019, at 17:48, Jonathan Morton <[email-masked]> wrote:
>>> 
>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <[email-masked]> wrote:
>>>> 
>>>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode.
>>> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:
>>> 
>>>>      Therefore, as soon as an
>>>>      AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
>>>>      both its half connections into the feedback mode shown in the
>>>>      rightmost column.
>>> - Jonathan Morton
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 11 Dec 2019 02:19:08 +0000

Mirja,

On 23/1119 I sent an analysis of the changes that would need to be made 
to the AccECN draft if it became stds track (which would imply that it 
then updates RFC3168) instead of expt track. For context, please read 
and possibly respond to that before you respond to this email.

However, my email below applies whether AccECN is stds track or expt track.

I've shifted the quoting back into order below, so the context is more 
clear, and I've then responded inline...
>>> [MK] Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me.
[BB] Please be clear exactly which requirements you are talking about. 
When I read the above, I just gave up and threw my laptop out of the 
window.

Having bought a new laptop, I'm now wondering... perhaps you didn't mean 
all of the normative requirements under table 2 when you said 'we should 
not have these normative requirements', altho from your earlier email I 
got the distinct impression you did mean that (which is why I wasted a 
laptop).

What did you mean? Given the considerable amount of normative language 
in this part of the draft, and that it's all been stable for all 16 
revisions since draft-kuehlewind-01, I think we deserve to see the 
actual text you are proposing, and some sound reasoning for why the 
current normative text suddenly all has to be junked.

more...

>>>
>>> [MK] Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.
>> [BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol.
>>

On 02/12/2019 11:15, Mirja Kuehlewind wrote:
> Hi Bob,
>
> Regarding the [above] sentence:
>
[BB] But an AccECN /server/ does not have to support RFC3168. It might 
be desirable to support 3168 as well as AccECN, but strictly it doesn't 
have to for interoperability - it can fall-back to non-ECN if it 
receives a 3168 SYN.

That was my reason for starting this thread. If an AccECN server 
supports 3168, it replies (0,0,1). But it can just not support 3168 at 
all. Then it replies (0,0,0).

However, it cannot do neither. Hence why I said it MUST respond to a 
3168 SYN with either (0,0,1) or (0,0,0).

This cannot be said by referring to 3168.
>> [MK] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.
[BB] This cannot be said by referring to RFC3168 either.

Bob

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 11 Dec 2019 09:48:18 +0100

Hi Bob,

Sorry about your laptop (but if I remember correctly, it was broken anyway…). I think we do agree (and did from the beginning). Yes, I think my first statement below was overly broad and I did not meant to remove all normative language from that section. I was only referring to language that talked about RFC3168 negotiation.

You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something like: “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.” Or something like that. That’s all :-)

Mirja

> On 11. Dec 2019, at 03:19, Bob Briscoe <[email-masked]> wrote:
> 
> Mirja,
> 
> On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email.
> 
> I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline...
> [BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window.
> 
> Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop).
> 
> What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked.
> 
> more...
> 
>>>> 
> [BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN.
> 
> That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0).
> 
> However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0).
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 11 Dec 2019 10:12:59 +0000

Mirja,

> You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something lik…
Pls respond to my two points (that keep getting overlooked), both 
starting with "This cannot be said by referring to 3168" further down 
the email.

Bob
>>>> [BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 11 Dec 2019 16:28:17 +0100

Hi Bob,

Sorry I think I just got a bit lost here.

>> [BB] This cannot be said by referring to RFC3168 either.

I’m not sure I understand what you mean, given that the combination with AE=1 is/needs to be discussion in this draft. Are we again talking past each other (but actually agree)?

Mirja

> On 11. Dec 2019, at 11:12, Bob Briscoe <[email-masked]> wrote:
> 
> Mirja,
> 
> Pls respond to my two points (that keep getting overlooked), both starting with "This cannot be said by referring to 3168" further down the email.
> 
> 
> Bob
>> 
>> Mirja
>> 
>> 
>>

---

From: Matt Mathis <[email-masked]>
Date: Wed, 11 Dec 2019 09:43:23 -0600

As a general strategy I would strongly prefer to wrap all 3168
compatibility language in SHOULDS, perhaps with a meta comment that this
language will all be obsolete at some point in the future.

I haven't been paying attention to a lot of this...  Is there a doc that
officially adjusts the standards status of 3168?  e.g. explicitly says "not
recommended for deployment in unsupervised contexts" (e.g. Siri is fine,
because Apple can turn it off or update it).

If not, the protocol lawyers will be upset about using SHOULDS to
deprecate a standard.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

We must not tolerate intolerance;
       however our response must be carefully measured:
            too strong would be hypocritical and risks spiraling out of
control;
            too weak risks being mistaken for tacit approval.

On Wed, Dec 11, 2019 at 4:13 AM Bob Briscoe <[email-masked]> wrote:

> > Sorry about your laptop (but if I remember correctly, it was broken
> anyway…). I think we do agree (and did from the beginning). Yes, I think my
> first statement below was overly broad and I did not meant to remove all
> normative language from that section. I was only referring to language that
> talked about RFC3168 negotiation.
> >
> > You propose below that an AccECN sender "MUST respond to a 3168 SYN with
> either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use
> normative language here but rather say something like: “If an AccECN sender
> received a 3168 SYN (without AE=1 respectively) is replies as specified in
> RFC3168 if it is configured to support classic ECN.” Or something like
> that. That’s all :-)
> to the AccECN draft if it became stds track (which would imply that it then
> updates RFC3168) instead of expt track. For context, please read and
> possibly respond to that before you respond to this email.
> >>
> >>>>> [MK] Sorry I wasn’t clear. I think we should not have these
> normative requirement in the draft and change the text to make it
> non-normative. This section was meant to explain which modes you end up in
> and the current use of normative language doesn’t seem to be right to me.
> When I read the above, I just gave up and threw my laptop out of the window.
> >>
> >> Having bought a new laptop, I'm now wondering... perhaps you didn't
> mean all of the normative requirements under table 2 when you said 'we
> should not have these normative requirements', altho from your earlier
> email I got the distinct impression you did mean that (which is why I
> wasted a laptop).
> >>
> revisions since draft-kuehlewind-01, I think we deserve to see the actual
> text you are proposing, and some sound reasoning for why the current
> normative text suddenly all has to be junked.
> >>
> >> more...
> >>
> >>>>> [MK] Likewise the table was also not meant to say whenever you
> implement AccECN, you MUST negotiate it in the handshake. And likewise the
> table does not show any classic ECN only transitions.
> >>>> [BB] In the spec of AccECN, it's necessary and reasonable to state
> normative requirements for a node "that is AccECN-enabled". That doesn't
> mean that an AccECN implementation has to always support AccECN - it can
> always disable AccECN. But we do have to say what it is expected to do if
> it is following the AccECN protocol.
> >>>>
> >>>> This draft has included that normative language for the negotiation
> phase in all 16 revisions since the first individual draft (that you
> wrote!).
> >>>>
> >>>> The table shows only cases where one end or the other is
> AccECN-capable, and the text preceding and following the table gives
> normative requirements solely for the AccECN node(s) in those cases. It
> doesn't give any normative requirements for non-AccECN nodes.
> >>>>
> >>>> In block 3, the server is AccECN capable, so in the AccECN spec. it's
> perfectly reasonable to say what it ought to do in response to various
> types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the
> AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.
> >>>>
> >>>> The only case that is in question, AFAIC, is whether we have to say
> what an AccECN-capable server does in response to a SYN from an RFC3168
> client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can
> respond with a SYN-ACK that is either RFC3168 or non-ECN.
> >>>>
> >>>> I just proposed respectively SHOULD and MAY, but I can now see there
> is no need to make that judgement call. However, it is still important to
> say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).
> >>> This is a normative statement that is defined in RFC3168 and we should
> not state it here again but refer to RFC3168 instead.
> have to for interoperability - it can fall-back to non-ECN if it receives a
> 3168 SYN.
> >>
> supports 3168, it replies (0,0,1). But it can just not support 3168 at all.
> Then it replies (0,0,0).
> >>
> >>>> [BB] It's also important that the spec defines all three bits in the
> SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the
> combinations with AE=1 are ruled out and therefore remain available for
> future use.
> >>>>>>> I don’t think we can or should derive a normative requirement from
> this table. The table rather explains which mode you are in depending on
> the handshake that has happened. So it says: when client A is ECN capable
> and requests classic ECN support in the handshake and server B is AccECN
> capable and negotiated classic ECN support in the handshake then you are in
> classic ECN mode.
> >>>>>> I will merely re-quote the final sentence from my quoted text,
> which transforms that table into a normative requirement:
> >>>>>>
> >>>>>>>      Therefore, as soon as an
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 11 Dec 2019 18:14:22 +0200

> On 11 Dec, 2019, at 5:43 pm, Matt Mathis <mattmathis=[email-masked]> wrote:
> 
> As a general strategy I would strongly prefer to wrap all 3168 compatibility language in SHOULDS, perhaps with a meta comment that this language will all be obsolete at some point in the future.   

I definitely object to the latter, not least because it's logically inconsistent with the handshake protocol.  Any AccECN client MUST be prepared to have their AccECN-requesting SYN interpreted as an RFC-3168 SYN by an RFC-3168 server, which will reply with an RFC-3168 SYN-ACK and thereby put the whole connection in RFC-3168 mode.

Therefore, RFC-3168 clients will always be at least as prevalent as AccECN clients, *even if* AccECN servers for some unfathomable reason decide to drop RFC-3168 support.  I maintain that the advantage to doing so is negligible in the most favourable interpretation.

Therefore, you *cannot* assume in AccECN specifications that RFC-3168 will "eventually" go away.

 - Jonathan Morton

---

From: Matt Mathis <[email-masked]>
Date: Wed, 11 Dec 2019 12:07:41 -0600

Content providers who are using some version of DCTCP are constrained to
use the same switch markings for all flows.  It is inconceivable that
anybody would do 3168 in such an environment, however DCTCP and AccECN are
likely to work well enough to fly.

I think you underestimate how quickly server side 3168 will evaporate once
AccECN is far enough along, especially if we are explicit about
discouraging distros from shipping it on by default, so the only server
side 3168 is by people who are engaged in the research.   Remember, by
default content providers must stay up to date with upstream bug fixes.

Thanks,
--MM--

On Wed, Dec 11, 2019 at 10:14 AM Jonathan Morton <[email-masked]>
wrote:

> I definitely object to the latter, not least because it's logically
> inconsistent with the handshake protocol.  Any AccECN client MUST be
> prepared to have their AccECN-requesting SYN interpreted as an RFC-3168 SYN
> by an RFC-3168 server, which will reply with an RFC-3168 SYN-ACK and
> thereby put the whole connection in RFC-3168 mode.
>
> Therefore, RFC-3168 clients will always be at least as prevalent as AccECN
> clients, *even if* AccECN servers for some unfathomable reason decide to
> drop RFC-3168 support.  I maintain that the advantage to doing so is
> negligible in the most favourable interpretation.
>

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 11 Dec 2019 21:58:53 +0200

> On 11 Dec, 2019, at 8:07 pm, Matt Mathis <[email-masked]> wrote:

> Content providers who are using some version of DCTCP are constrained to use the same switch markings for all flows.  It is inconceivable that anybody would do 3168 in such an environment, however DCTCP and AccECN are likely to work well enough to fly.

Content providers SHOULD NOT be using DCTCP on the open Internet.  That is the environment with which I am chiefly concerned.

If they want to screw up their internal environments, that's no skin off my nose.

> I think you underestimate how quickly server side 3168 will evaporate once AccECN is far enough along, especially if we are explicit about discouraging distros from shipping it on by default, so the only server side 3168 is by people who are engaged in the research.   Remember, by default content providers must stay up to date with upstream bug fixes.

In other words, you are actively advocating for the deprecation of RFC-3168, just as it is gaining traction and actively being deployed in the real world.  You may expect me to object to that at every opportunity, given the work I've put into ECN-related technologies in the past several years, and the clear advantages that RFC-3168 shows for general Internet traffic.  I think certain industry members would also object on a similar basis.

If I may be cynical for a moment, I also note that coexistence between AccECN/L4S and SCE was a topic discussed at and around IETF-106.  This is one of the cornerstones of potentially allowing the L4S and SCE experiments to run in parallel, and we in the SCE team have been careful to ensure that we can coexist with AccECN/L4S endpoints, on the assumption that both schemes would retain RFC-3168 compliance as a fallback position.  This notion that dropping RFC-3168 support would become the norm appears, to us, to be explicitly designed to damage SCE's prospects.  I sincerely hope that is not actually the case, but given appearances I would ask for a clarification of that point.

The existing text in AccECN mandates falling back both halves of the connection to RFC-3168 mode if either end supports it but not AccECN, and the other end supports AccECN.  I supported moving AccECN forward (as EXP) with that language in place.  I would feel obliged to withdraw that support if the text were changed to make RFC-3168 support any less than a SHOULD at the server end and a MUST at the client end - noting that the definition of SHOULD is that a pretty solid justification has to be made for not following the point.

 - Jonathan Morton

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 12 Dec 2019 00:13:38 +0000

Mirja,

> I’m not sure I understand what you mean, given that the combination with AE=1 is/needs to be discussion in this draft. Are we again talking past each other (but actually agree)?
In the context of these two rows in table 2:

    +--------+--------+------------+-----------+------------------------+
    | A      | B      |  SYN A->B  |  SYN/ACK  | Feedback Mode          |
    |        |        |            |    B->A   |                        |
    +--------+--------+------------+-----------+------------------------+
    |        |        | AE CWR ECE | AE CWR ECE|                        |
...
    | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            |
...
    | ECN    | AccECN | 0   1   1  | 0   0   1 | classic ECN            |

In the first case, I'm saying the AccECN client (A) only falls back to 
classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in 
response to a 111 SYN is reserved for future use. Whereas if in this 
case we merely said an AccECN client does what RFC3168 says, the AccECN 
client would have to switch to classic ECN if the SYN/ACK was X01, thus 
wasting a codepoint.

In the second case, the AccECN server only falls back to classic ECN 
mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 
SYN is reserved for future use. Whereas, if in this case we merely said 
an AccECN server does what RFC3168 says, the server would have to switch 
to classic ECN if the SYN was X11, thus wasting another codepoint.

This is a separate point from the MUST vs SHOULD language in the second 
case. I'll respond to Jonathan on that next.

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 12 Dec 2019 01:36:49 +0000

Jonathan,

> The existing text in AccECN mandates falling back both halves of the connection to RFC-3168 mode if either end supports it but not AccECN, and the other end supports AccECN.  I supported moving Acc…
I think you are labouring under the common misconception that the IETF 
uses MUST or SHOULD language to advise implementers what the IETF thinks 
they ought to do. That's not the role of the IETF. MUST or SHOULD 
language tells an implementer who already wants to comply with an RFC, 
what is necessary or desirable to do to interoperate with others who 
also want to comply with that RFC. The initial decision on whether to 
choose to comply with an RFC is up to each implementer.

Don't worry, the AccECN spec says that the client MUST be able to 
fall-back to classic ECN support.

But it's not the IETF's role to tell an AccECN server implementer that 
they SHOULD fall back to classic ECN because that's not necessary for 
interoperation. All we need to say for interop is that an AccECN server 
that receives a classic ECN SYN MUST fall back to either classic ECN or 
non-ECN.

I've suggested some wording below to hint to implementers which choice 
they are likely to want to make. And I've only shown the ECN fallback 
case in the table, which is probably as much as many implementers will 
bother reading.

However, it would be an abuse of normative text to tell implementers 
they "SHOULD" make one of these choices - that's an improper use of 
"SHOULD" for evangelism rather than interoperability. We don't need to 
tell an implementer to act in their own best interests - they can work 
out for themselves that falling back to ECN gives better performance 
than non-ECN.

    3.  The third block shows the cases where the TCP server (B) supports
        AccECN but the TCP client (A) supports some earlier variant of
        TCP feedback, indicated in its SYN.

        When an AccECN-enabled TCP server (B) receives a SYN with
        AE,CWR,ECE = 0,1,1 it MUST do one of the following:

        *  set both its half connections into the classic ECN feedback
           mode and return a SYN/ACK with AE, CWR, ECE = 0,0,1 as shown.
           Then it MUST comply with with [RFC3168].

        *  set both its half-connections into No ECN mode and return a
           SYN/ACK with AE,CWR,ECE = 0,0,0.  This latter case is unlikely
           to be desirable, but it is allowed as a possibility, e.g. for
           minimal TCP implementations.

        When an AccECN-enabled TCP server (B) receives a SYN with
        AE,CWR,ECE = 0,0,0 it MUST set both its half connections into the
        Not ECN feedback mode and return a SYN/ACK with AE,CWR,ECE =
        0,0,0 as shown.

Bob

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 12 Dec 2019 10:16:52 +0100

Hi Bob,

Please see inline below.

> On 12. Dec 2019, at 01:13, Bob Briscoe <[email-masked]> wrote:
> 
> Mirja,
> 
> In the first case, I'm saying the AccECN client (A) only falls back to classic ECN mode if the SYN/ACK is 001. This ensures a 101 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas if in this case we merely said an AccECN client does what RFC3168 says, the AccECN client would have to switch to classic ECN if the SYN/ACK was X01, thus wasting a codepoint. 

In this case the A has requested AccECN support but B only supports classic ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is received negotiation is done and A has to act as specified in RFC3168.

If B would reply with 101 in the SYN/ACK, then B is also an AccECN sender but wants to negotiate something that is not yet specified. 

I don’t see any problem here.

> 
> In the second case, the AccECN server only falls back to classic ECN mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 SYN is reserved for future use. Whereas, if in this case we merely said an AccECN server does what RFC3168 says, the server would have to switch to classic ECN if the SYN was X11, thus wasting another codepoint.

In the case where A requests classic ECN, B can still decide to either support classic ECN or not and respectively reply with 001 or 000. And all I’m saying that we should not specify this reply here because that’s already specified in RFC3168.

If A sends 111 it’s not a classic ECN sender and we can still specify it here but that’s not the case that is shown in the table. 

Mirja

> 
> 
> This is a separate point from the MUST vs SHOULD language in the second case. I'll respond to Jonathan on that next.
> 
> 
> Bob
> 
>> 
>> Mirja
>> 
>> 
>> 
>>

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 12 Dec 2019 14:53:07 +0000

Mirja,

On 12/12/2019 09:16, Mirja Kuehlewind wrote:
> Hi Bob,
>
> Please see inline below.
>
>> On 12. Dec 2019, at 01:13, Bob Briscoe<[email-masked]>  wrote:
>>
>> Mirja,
>>
You were saying we should just refer to RFC3168 in this case. I am 
saying we should not refer to RFC3168 for the wire protocol aspect. 
Rather we should specify the wire protocol part in the AccECN spec, 
because we can specify more tightly than RFC3168 that only a 001 SYN/ACK 
causes the client to fall back to classic ECN, whereas it would be an 
X01 SYN/ACK if we referred to 3168.

This was originally just a very minor disagreement about not referring 
off to another spec, but it got detached from its original context by 
the way the responses were posted.

Here's suggested text. Changes from -09 are in green:

    | AccECN | Nonce  | 1   1   1  | 1   0   1 |(Reserved)              |
    | AccECN | ECN    | 1   1   1  | 0   0   1 | classic ECN            |
    | AccECN | No ECN | 1   1   1  | 0   0   0 | Not ECN                |

    2.  The second block shows the cases where the TCP client (A)
        supports AccECN but the TCP server (B) supports some earlier
        variant of TCP feedback, indicated in its SYN/ACK.  Therefore, as
        soon as an AccECN-capable TCP client (A) receives the SYN/ACK
        shown it MUST set both its half connections into the feedback
        mode shown in the rightmost column.If it has set itself into classic ECN feedback mode it MUST then comply 
with [RFC3168].

Note that I've referred to RFC3168 for the behaviour after the wire 
protocol negotiation, but that's something I've been tightening up 
separately from this conversation.

Note that in the Nonce row, now that it's historic, I realized we 
should've changed "classic ECN" to "(Reserved)", so as not to burn that 
codepoint.

>> <STRIKETHROUGH>
>> </STRIKETHROUGH>
Sorry, please consider my para above to be deleted. It was rubbish. I 
was just about to send a correction to my own posting when this response 
of yours came in. My response to your point below replaces it.

> In the case where A requests classic ECN, B can still decide to either support classic ECN or not and respectively reply with 001 or 000. And all I’m saying that we should not specify this reply he…
I admit that I'd prefer not to add all that text to the AccECN spec that 
I suggested (in my response to Jonathan). However, my concern about 
referring off to RFC3168 is that there is so much about this in RFC3168, 
it is difficult to be specific about which bits of 3168 we mean and 
which bits we don't. Let's start from your suggested text:

    “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.”

I'll first just correct 'sender' to 'server' and make it more consistent 
with the current style of the AccECN text:

    "When an AccECN-enabled TCP server (B) receives a SYN with
    AE,CWR,ECE = 0,1,1 it replies as specified in RFC3168 if it is
    configured to support classic ECN."

That's nice in that it side-steps the controversy we have over whether 
to support classic ECN.
But it doesn't say what a server does if it is not configured to support 
classic ECN.
And it doesn't say that the SYN/ACK has to have AE=0 (although that is 
in the table).

This seems to be a disagreement over whether to write spec as precisely 
as pseudocode, or whether to write it on the assumption that an 
implementer will probably guess what we mean where we omit stuff that we 
think is obvious.

Bob

>>>> On 11. Dec 2019, at 11:12, Bob Briscoe<[email-masked]>
>>>>   wrote:
>>>>
>>>> Mirja,
>>>>
>>>>>> On 11. Dec 2019, at 03:19, Bob Briscoe<[email-masked]>
>>>>>>   wrote:
>>>>>>
>>>>>> Mirja,
>>>>>>
>>>>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe<[email-masked]>
>>>>>>>>   wrote:
>>>>>>>>
>>>>>>>> Mirja,
>>>>>>>>
>>>>>>>>
>>>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton<[email-masked]>
>>>>>>>>>>   wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind<[email-masked]>
>>>>>>>>>>>   wrote:
>>>>>>>>>>>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: Matt Mathis <[email-masked]>
Date: Thu, 12 Dec 2019 09:07:47 -0600

If the only choice is to downgrade to non-ECN, it would make the code and
documentation simpler.  It also has the property that you might be able to
reuse the 3168 codepoint in a couple of years (well, ok a decade).

Is there any reason to want to have 3168 and AccECN coexistence beyond a
transition?  Put another way, if we imagine fully supporting both 3168 and
AccECN, it there any reason to choose 3168 other than deployment inertia?

Thanks,
--MM--

On Thu, Dec 12, 2019 at 3:17 AM Mirja Kuehlewind <[email-masked]>
wrote:

> >>>>>> [BB] It's also important that the spec defines all three bits in
> the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the
> >> I’m not sure I understand what you mean, given that the combination
> with AE=1 is/needs to be discussion in this draft. Are we again talking
> past each other (but actually agree)?
> response to a 111 SYN is reserved for future use. Whereas if in this case
> we merely said an AccECN client does what RFC3168 says, the AccECN client
> would have to switch to classic ECN if the SYN/ACK was X01, thus wasting a
> codepoint.
>
>
> In this case the A has requested AccECN support but B only supports
> classic ECN and indicates that in the SYN/ACK. As soon as the SYN/ACK is
> received negotiation is done and A has to act as specified in RFC3168.
>
> If B would reply with 101 in the SYN/ACK, then B is also an AccECN sender
> but wants to negotiate something that is not yet specified.
>
> mode if the SYN is 011. This ensures a 001 SYN/ACK in response to a 111 SYN
> is reserved for future use. Whereas, if in this case we merely said an
> AccECN server does what RFC3168 says, the server would have to switch to
> classic ECN if the SYN was X11, thus wasting another codepoint.
>
> In the case where A requests classic ECN, B can still decide to either
> support classic ECN or not and respectively reply with 001 or 000. And all
> I’m saying that we should not specify this reply here because that’s
> already specified in RFC3168.
>
> If A sends 111 it’s not a classic ECN sender and we can still specify it
> here but that’s not the case that is shown in the table.
>
> Mirja
>
>
>
> >
> >
> >>>> You propose below that an AccECN sender "MUST respond to a 3168 SYN
> with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not
> use normative language here but rather say something like: “If an AccECN
> sender received a 3168 SYN (without AE=1 respectively) is replies as
> specified in RFC3168 if it is configured to support classic ECN.” Or
> something like that. That’s all :-)
> >>>>
> starting with "This cannot be said by referring to 3168" further down the
> email.
> >>>
> >>>
> >>> Bob
> >>>
> >>>> Mirja
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 23/1119 I sent an analysis of the changes that would need to be
> made to the AccECN draft if it became stds track (which would imply that it
> then updates RFC3168) instead of expt track. For context, please read and
> >>>>> I've shifted the quoting back into order below, so the context is
> more clear, and I've then responded inline...
> >>>>>
> >>>>> [BB] Please be clear exactly which requirements you are talking
> about. When I read the above, I just gave up and threw my laptop out of the
> window.
> >>>>>
> >>>>> What did you mean? Given the considerable amount of normative
> language in this part of the draft, and that it's all been stable for all
> 16 revisions since draft-kuehlewind-01, I think we deserve to see the
> actual text you are proposing, and some sound reasoning for why the current
> >>>>>>> This draft has included that normative language for the
> negotiation phase in all 16 revisions since the first individual draft
> (that you wrote!).
> >>>>>>>
> >>>>>>> In block 3, the server is AccECN capable, so in the AccECN spec.
> it's perfectly reasonable to say what it ought to do in response to various
> >>>>>>> The only case that is in question, AFAIC, is whether we have to
> say what an AccECN-capable server does in response to a SYN from an RFC3168
> >>>>>>> I just proposed respectively SHOULD and MAY, but I can now see
> there is no need to make that judgement call. However, it is still
> important to say an AccECN-enabled server MUST respond with either (0,0,1)
> or (0,0,0).
> >>>>>>>
> >>>>>> This is a normative statement that is defined in RFC3168 and we
> should not state it here again but refer to RFC3168 instead.
> >>>>>>
> >>>>> [BB] But an AccECN /server/ does not have to support RFC3168. It
> might be desirable to support 3168 as well as AccECN, but strictly it
> doesn't have to for interoperability - it can fall-back to non-ECN if it
> receives a 3168 SYN.
> >>>>>
> >>>>>>> [BB] It's also important that the spec defines all three bits in
> the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the
> >>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton <
> [email-masked]>
> >>>>>>>>>  wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <
> [email-masked]>
> >>>>>>>>>>  wrote:
> >>>>>>>>>>
> >>>>>>>>>> I don’t think we can or should derive a normative requirement
> from this table. The table rather explains which mode you are in depending
> on the handshake that has happened. So it says: when client A is ECN
> capable and requests classic ECN support in the handshake and server B is
> AccECN capable and negotiated classic ECN support in the handshake then you
> are in classic ECN mode.
> >>>>>>>>>>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 12 Dec 2019 17:28:19 +0100

> should've changed "classic ECN" to "(Reserved)", so as not to burn that

A further comments here: Since Nonce is historic, should it even be
mentioned as a possible server behavior at all, in this table?

While the initial nonce sum was set to 1, and supposed to be included in
the SYN,ACK, a mangling of IP ECN bits could conceivable have masked
this (and a L4S sender, setting ECT1 on the SYN, would elicit the same
SYN,ACK response from both a RFC3168 server, as well as a RFC3540 Nonce
server...)

To be clear - I'd swap out the "Nonce" server to "Resrvd" or "Future"
(or SCE :) )...

Richard

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 12 Dec 2019 17:33:46 +0100

I want to note, that the deployment inertia is already there in generic
IP-level ECN support - not only the end hosts.

Interestingly, certain carrier-class gear doesn't support ECN at all,
while other data-center class gear ONLY supports the DCTCP / L4S variant
of instanteous, shallow queue marking...

I guess that is an argument (or rather hint) along the same lines, for
eventual phasing-out of RFC3168 ECN....

Richard

Am 12.12.2019 um 16:07 schrieb Matt Mathis:
> If the only choice is to downgrade to non-ECN, it would make the code
> and documentation simpler.  It also has the property that you might be
> able to reuse the 3168 codepoint in a couple of years (well, ok a decade).
>
> transition?  Put another way, if we imagine fully supporting both 3168
> and AccECN, it there any reason to choose 3168 other than deployment
> inertia?
>
> Thanks,
> --MM--

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 12 Dec 2019 17:39:38 +0100

Hi Matt,

AccECN was always backward compatible with classic ECN, meaning when the sender of the SYN requests AccECN (111) and the receiver does not understand AccECN is will ignore the AE (former NS) bit and only see (11) and think the sender requested classic ECN and may decide to negotiate it, otherwise we would not be able to reuse the ECN TCP bit at all.

Mirja

> On 12. Dec 2019, at 16:07, Matt Mathis <[email-masked]> wrote:
> 
> Bob you said:
> >Don't worry, the AccECN spec says that the client MUST be able to fall-back to classic ECN support.
> 
> If the only choice is to downgrade to non-ECN, it would make the code and documentation simpler.  It also has the property that you might be able to reuse the 3168 codepoint in a couple of years (well, ok a decade).
> 
> Is there any reason to want to have 3168 and AccECN coexistence beyond a transition?  Put another way, if we imagine fully supporting both 3168 and AccECN, it there any reason to choose 3168 other than deployment inertia?
> 
> Thanks,
> --MM--
>             too strong would be hypocritical and risks spiraling out of control;
> On Thu, Dec 12, 2019 at 3:17 AM Mirja Kuehlewind <[email-masked]> wrote:
> Hi Bob,
> 
> Please see inline below.
>

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 12 Dec 2019 20:32:27 +0200

> On 12 Dec, 2019, at 5:07 pm, Matt Mathis <mattmathis=[email-masked]> wrote:
> 

Because there are still potential valid experiments which build upon RFC-3168 signalling, including SCE, which may yet prove popular.  I think it would be exceedingly short-sighted to prevent such experiments from succeeding, and not just because I happen to be involved in one.

And because there's an *awful lot* of RFC-3168 compliant endpoints out there.  Every current Apple product requests RFC-3168 ECN by default.  Some major Linux distros do as well, and for all others it's a mere sysctl away.  Even Windows users can turn it on just as easily, though it is not on by default.

The ECN-aware middleboxes intended for use on last-mile links and as wifi APs also universally signal in the RFC-3168 manner and expect an RFC-3168 (or RFC-8511) compliant response.  I've found CPE advertising support for exactly this on the shelf.  The recent "make wifi fast" modifications to the Linux wifi stack include a built-in fq_codel AQM for the very common ath9k, ath10k and mt76 hardware.

That deployment remains low in the carrier-grade market is increasingly anomalous (and mostly due to a chicken-and-egg situation whereby carriers can't turn it on because HW doesn't support it, and HW vendors don't implement it because their customers don't make a stink about it).  Nevertheless, at least two major European ISPs are known to have deployed fq_codel in both directions, in the name of improving customers' QoS.

This is what I mean by RFC-3168 deployment "taking off" in the past few years.  There's a lot more of it now than there was five years ago, due in large part to the superlative performance of Codel AQM - which is *specifically* designed around RFC-3168 response characteristics.  We've already discussed this somewhat in TSVWG.

 - Jonathan Morton

---

From: "Richard Scheffenegger" <[email-masked]>
Date: Thu, 12 Dec 2019 19:53:22 +0100

Just remember that windows will nowadays go with dctcp if you turn on ecn, and the server is less than 10ms rtt away (which is possible in cities where a cdn colocates with your isp...)

Just sayin’ :)

Gesendet mit der GMX Mail App

Am 12.12.19 um 19:32 schrieb Jonathan Morton

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 27 Dec 2019 19:03:14 +0000

To clarify Windows Server will do that but not any of the client editions. And the default for Server has also been flipped to CUBIC in the most recent release. 

-----Original Message-----
From: tcpm <[email-masked]> On Behalf Of Richard Scheffenegger
Sent: Thursday, December 12, 2019 10:53 AM
To: Jonathan Morton <[email-masked]>
Cc: Matt Mathis <mattmathis=[email-masked]>; tcpm IETF list <[email-masked]>; Mirja Kuehlewind <[email-masked]>
Subject: [EXTERNAL] Re: [tcpm] A possible simplification for AccECN servers

Just sayin’ :)

_______________________________________________
tcpm mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7C2137c81afa6143286c9308d77f349992%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637117736214183837&amp;sdata=d8q8I53jQUzu01fVI%2FbGf97tVXHcSYSrUrZvMRPo0gw%3D&amp;reserved=0