Re: [tcpm] A possible simplification for AccECN servers

[Matt Mathis <[e-mail]>]

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--
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 Thu, Dec 12, 2019 at 3:17 AM Mirja Kuehlewind <[e-mail]>
wrote:

> Hi Bob,
>
> Please see inline below.
>
> > On 12. Dec 2019, at 01:13, Bob Briscoe <[e-mail]> wrote:
> >
> > Mirja,
> >
> > On 11/12/2019 15:28, Mirja Kuehlewind wrote:
> >> Hi Bob,
> >>
> >> Sorry I think I just got a bit lost here.
> >>
> >> So this point:
> >>
> >>>>>> [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.
> >>>>>>
> >>>> [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)?
> > 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 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
> >>
> >>
> >>
> >>
> >>> On 11. Dec 2019, at 11:12, Bob Briscoe <[e-mail]>
> >>>  wrote:
> >>>
> >>> Mirja,
> >>>
> >>> On 11/12/2019 08:48, Mirja Kuehlewind wrote:
> >>>
> >>>> 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 :-)
> >>>>
> >>> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On 11. Dec 2019, at 03:19, Bob Briscoe <[e-mail]>
> >>>>>  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.
> >>>>>
> >>>>> 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...
> >>>>>
> >>>>>>> On 25. Nov 2019, at 22:41, Bob Briscoe <[e-mail]>
> >>>>>>>  wrote:
> >>>>>>>
> >>>>>>> Mirja,
> >>>>>>>
> >>>>>>>
> >>>>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
> >>>>>>>
> >>>>>>>> Hi Jonathan,
> >>>>>>>>
> >>>>>>>> [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.
> >>>>>>>
> >>>>>>> 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).
> >>>>>>>
> >>>>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:
> >>>>>
> >>>>>> Hi Bob,
> >>>>>>
> >>>>>> Regarding the [above] sentence:
> >>>>>>
> >>>>>> 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.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>>>> [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.
> >>>>>>>
> >>>>> [BB] This cannot be said by referring to RFC3168 either.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Bob
> >>>>>
> >>>>>>>
> >>>>>>> Bob
> >>>>>>>
> >>>>>>>> Mirja
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On 25. Nov 2019, at 17:48, Jonathan Morton <
> [e-mail]>
> >>>>>>>>>  wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <
> [e-mail]>
> >>>>>>>>>>  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/
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> ________________________________________________________________
> >>>>> Bob Briscoe
> >>>>> http://bobbriscoe.net/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>> --
> >>> ________________________________________________________________
> >>> Bob Briscoe
> >>> http://bobbriscoe.net/
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > ________________________________________________________________
> > Bob Briscoe
> > http://bobbriscoe.net/
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>