Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn

From: Pete Heist <[email-masked]>
Date: Fri, 8 Nov 2019 08:22:51 +0000

Hi,

Regarding points A1 and B overall, would it be possible to add to the AccECN draft some language such that when it falls back to RFC 3168 ECN, the NS bit is still available for other experiments? That way the bit could still be used by SCE, even if AccECN becomes a proposed standard.

> From: Yoshifumi Nishida <[email-masked]>
> Date: Thu, 7 Nov 2019 11:04:38 -0800
> 
> Hi,
> draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn have been
> discussed for a while.
> tcpm chairs are now thinking that they are getting matured and becoming
> ready for WGLC .
> However, we also think there are several points to be clarified beforehand.
> 
> In order to proceed the current situation, we would like to ask the
> community to give some feedback on the following points.
> We will highly appreciate your inputs.
> 
> A: Allocating bit 7 for draft-ietf-tcpm-accurate-ecn
>  The draft requests the allocation for bit 7 in TCP header (ex NS bit)
> for this proposal.
>  However, the intended status of the draft is experimental, which may not
> be well aligned with the description in RFC2780.
> 
> The chairs would like to check the following points.
>     A1: If we can have a consensus to allocate bit 7 for this
> experimental draft. Or, if there is any other ways to allow the allocation
> (e.g. using other documents)
>     A2: if we decide to allocate the bit, what we should do when the
> experiment fails.
> 
> B: Overlaps with some congestion experienced proposals
>  It seems that some congestion experienced proposals
> (draft-grimes-tcpm-tcpsce
> and draft-morton-tsvwg-sce) have similarities with these drafts.
> 
>  The chairs would like to check the following points for this.
>    B1: The two proposals won't conflict each other. We can discuss and
> proceed these proposals separately without any potential risks.
>    B2: it seems that SCE and L4S may have some conflicts, but this will
> not affect the discussions for AccECN and ECN++.
>    B3: if we allocate the bit 7 for AccECN, it is still allowed for SCE
> proposals to use the bit or it will be prohibited.
> 
>  BTW, just in case. please avoid initiating technical discussions and try
> to discuss how to proceed the drafts in this thread.
> --
> Yoshi on behalf of tcpm chairs

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 12 Nov 2019 16:30:07 +0000

Peter, I don't think the AccECN draft should say anything about what happens to the ex-NS bit if it falls back to classic ECN because that's out of scope of the draft defining the AccECN mechanis. However, I agree that is would be available for another use.

Yoshi, I believe you point A1 below was decided in the group already at adoption time as the bit was used from the beginning with all possible AccECN mechanisms. However, if and how it should be registered with IANA is a different question. To my memory there was support to registered even though it's experimental because NS was registered based on an experimental RFC and having this registry saying something about this specific bit while not noting this experiment there seems confusing/against the idea of a registry. What we maybe could discuss is if we want to rename the bit in the registry (to AE) or rather just add a note about this experiment. Last time there was support to give it a proper name which we followed as authors but of course it's the working group to decide here.

Regarding point A2, this was also discussed at length in the group. There are different way of failing. One is, as we saw for NS, that there will be no deployment at all and we can simply reassign. Another it that is gets deploy but doesn't work as expected, however, in this case there are still ways to extend/alter AccECN by negotiation during the handshake. This is also discussed in the draft and the mayor reason for having the handshake negotiation instead of just using the bit (as some other proposal do). If that is not good enough, I'm afraid we won't be able to ever use any of the reserved bits in the TCP handshake.

Regarding your point B below I don't see any dependency FROM AccECN to any of these proposals. Yes, multiple proposal reply on AccECN, which it great because it show that it is useful, but that only means that the proposals have a dependency TO AccECN and not the other way around. For me this is another reason to proceed with AccECN quickly.

Mirja

On 08.11.19, 09:23, "tcpm on behalf of Pete Heist" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    > to discuss how to proceed the drafts in this thread.
    
    _______________________________________________
    tcpm mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tcpm

---

From: Pete Heist <[email-masked]>
Date: Tue, 12 Nov 2019 19:54:37 +0100

> On Nov 12, 2019, at 5:30 PM, Mirja Kuehlewind <[email-masked]> wrote:
> 

Ok, thanks for the reply, if the allocation of that bit is not exclusive and it may still be used if AccECN is not negotiated, it sounds like that will work out.

Regards,
Pete

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 13 Nov 2019 00:08:54 -0800

Hi Mirja,

Thanks for the response.

On Tue, Nov 12, 2019 at 8:30 AM Mirja Kuehlewind <
[email-masked]> wrote:

> Peter, I don't think the AccECN draft should say anything about what
> happens to the ex-NS bit if it falls back to classic ECN because that's out
> of scope of the draft defining the AccECN mechanis. However, I agree that
> is would be available for another use.
>

Well, this might be just my personal opinion, but two drafts
(draft-ietf-tcpm-accurate-ecn and draft-grimes-tcpm-tcpsce-00) claim to
name ex-NS bit as AE and ESCE without any explanations for each other.
This looks confusing to me.

Yoshi, I believe you point A1 below was decided in the group already at
> adoption time as the bit was used from the beginning with all possible
> AccECN mechanisms. However, if and how it should be registered with IANA is
> a different question. To my memory there was support to registered even
> though it's experimental because NS was registered based on an experimental
> RFC and having this registry saying something about this specific bit while
> not noting this experiment there seems confusing/against the idea of a
> registry. What we maybe could discuss is if we want to rename the bit in
> the registry (to AE) or rather just add a note about this experiment. Last
> time there was support to give it a proper name which we followed as
> authors but of course it's the working group to decide here.
>

I see. I personally would like to select one before WGLC unless we see
solid reason that this is not necessary.

Adding a note about the experiment looks a relatively easier path to me
rather than allocating a bit for experimental doc. But, if we adopt SCE,
we'll need to update the description.
Or, creating a small PS doc to allocate a bit could be an idea as well.

> Regarding point A2, this was also discussed at length in the group. There
> are different way of failing. One is, as we saw for NS, that there will be
> no deployment at all and we can simply reassign. Another it that is gets
> deploy but doesn't work as expected, however, in this case there are still
> ways to extend/alter AccECN by negotiation during the handshake. This is
> also discussed in the draft and the mayor reason for having the handshake
> negotiation instead of just using the bit (as some other proposal do). If
> that is not good enough, I'm afraid we won't be able to ever use any of the
> reserved bits in the TCP handshake.
>

OK.

>
> Regarding your point B below I don't see any dependency FROM AccECN to any
> of these proposals. Yes, multiple proposal reply on AccECN, which it great
> because it show that it is useful, but that only means that the proposals
> have a dependency TO AccECN and not the other way around. For me this is
> another reason to proceed with AccECN quickly.
>

OK. just for clarification.
For example,  in near future, some middleboxes may implement a marking
algorithm which depends on AccECN, while other middleboxes may implement a
marking algorithm which doesn't depend on AccECN.
These middleboxes happen to be on the same path, then the packet marking
results will be a mix of two algorithms as middleboxes cannot identify
which TCP flows use AccECN or not.
But, AccECN is just designed to report what it received whether they are
mixed results or not. Hence, you say that AccECN is independent from these
potential conflicts. Correct?

--
Yoshi

>     Regarding points A1 and B overall, would it be possible to add to the
> AccECN draft some language such that when it falls back to RFC 3168 ECN,
> the NS bit is still available for other experiments? That way the bit could
> still be used by SCE, even if AccECN becomes a proposed standard.
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Nov 2019 11:38:57 +0000

Hi Yoshi,

see some comments in line (marked with [MK]).

Mirja

From: Yoshifumi Nishida <[email-masked]>
Date: Wednesday, 13. November 2019 at 09:09
To: Mirja Kuehlewind <[email-masked]>
Cc: Pete Heist <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn

Hi Mirja,

Thanks for the response.

On Tue, Nov 12, 2019 at 8:30 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Peter, I don't think the AccECN draft should say anything about what happens to the ex-NS bit if it falls back to classic ECN because that's out of scope of the draft defining the AccECN mechanis. However, I agree that is would be available for another use.

Well, this might be just my personal opinion, but two drafts (draft-ietf-tcpm-accurate-ecn and draft-grimes-tcpm-tcpsce-00) claim to name ex-NS bit as AE and ESCE without any explanations for each other.
This looks confusing to me.

[MK] Yes that is a little confusing but on the other hand these are two different mechanism. I think we first need to have a discussion if there is interest in TCP-SCE in the group before we decide to change anything in the AccECN draft, but I guess we discuss also finding a more neutral name or if allocated under this name the TCP-SCE should alos use it (as they are currently call it NS bit).

I see. I personally would like to select one before WGLC unless we see solid reason that this is not necessary.

[MK] I don’t see a dependency on TCP-SCE except the name. However discussion on TCP-SCE just started and I don’t want to further delay AccECN which is already stable for a long time. If it’s just about changing a name without any technical impact that can be done any time in process (before final publication).

Adding a note about the experiment looks a relatively easier path to me rather than allocating a bit for experimental doc. But, if we adopt SCE, we'll need to update the description.
Or, creating a small PS doc to allocate a bit could be an idea as well.

[MK] That’s something we should discuss now.

OK.

OK. just for clarification.
For example,  in near future, some middleboxes may implement a marking algorithm which depends on AccECN, while other middleboxes may implement a marking algorithm which doesn't depend on AccECN.
These middleboxes happen to be on the same path, then the packet marking results will be a mix of two algorithms as middleboxes cannot identify which TCP flows use AccECN or not.
But, AccECN is just designed to report what it received whether they are mixed results or not. Hence, you say that AccECN is independent from these potential conflicts. Correct?

[MK] Correct. AccECN really is only the feedback signal and I think L4S would e.g. address what you describe above (as one example). But we really tried to de-couple that because a) as it turned out is was already not great to have these things mixed up in one RFC for classic ECN and b) it’s also useful for other things (that don’t) change the congestion response, e.g. ECN++.

--
Yoshi

On 08.11.19, 09:23, "tcpm on behalf of Pete Heist" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi,

    > From: Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>>

    _______________________________________________
    tcpm mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Wed, 13 Nov 2019 06:39:04 -0800 (PST)

Hello Mirja, Yoshi, etc al,

Some comments in line (marked with [RWG]

Regards,
Rod

> Peter, I don't think the AccECN draft should say anything about what happens to the ex-NS bit if it falls back to classic ECN because that's out of scope of the draft defining the AccECN mechanis.…

 [RWG] Perhaps that is all that would need to be added?  "The newly allocated AE bit would be avaliable for other uses should AccECN fail to negotiate."

> [MK] Yes that is a little confusing but on the other hand these are two different mechanism. I think we first need to have a discussion if there is interest in TCP-SCE in the group before we decide…

 [RWG] TCP-SCE calls this bit ESCE (Echo SCE) due to its parallels with CE/ECE.  I have tried to minimize referense to NS in the latest version of the draft.

> [MK] I don?t see a dependency on TCP-SCE except the name. However discussion on TCP-SCE just started and I don?t want to further delay AccECN which is already stable for a long time. If it?s just about changing a name without any technical impact that can be done any time in process (before final publication).
> 
> [MK] That?s something we should discuss now.
> 
> 

 [RWG] I believe one of the major reasons that the negotiation MUST occur before doing AccECN is that it redifines the meaning of the CE bit in IP (this is an arguable point, I understand it just counts them and feeds back how many occured, but this is mainly so that L4S can use them in a high fadelity marking scheme), and ECE bit in TCP, I find that redifinition of an IP layer bit based on a TCP layer negotation problematic, see more below.

> But, AccECN is just designed to report what it received whether they are mixed results or not. Hence, you say that AccECN is independent from these potential conflicts. Correct?

 [RWG] Yoshi I agree that there are concerns here that should be looked at very carefully, the ECT(1) bit used to classify L4S traffic is the crux of that issue.

> [MK] Correct. AccECN really is only the feedback signal and I think L4S would e.g. address what you describe above (as one example). But we really tried to de-couple that because a) as it turned out is was already not great to have these things mixed up in one RFC for classic ECN and b) it?s also useful for other things (that don?t) change the congestion response, e.g. ECN++.

 [RWG] Mirja it appears that the design of AccECN is heavily biased towards support for L4S, giving that counting CE is the main feedback element, and that L4S is desgined to create more CE marks when in use.  This is one reason that SCE rejected AccECN as a viable solution for closing the feedback loop in SCE at the TCP layer, it is actually ECT(1) mark counts that needs high fadelity feedback as CE rarely occurs in the SCE design (it is a backstop failure mechansim for SCE to retain ECN3168 behavior.)  We do understand that a count of ECT(1) is avaliable, but that it requires a TCP option to get at it.

-- 
Rod Grimes                                                 [email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 13 Nov 2019 16:04:27 +0000

HI Rod,

just quickly one comment on this part:

"[RWG] Mirja it appears that the design of AccECN is heavily biased towards support for L4S, giving that counting CE is the main feedback element, and that L4S is desgined to create more CE marks when in use.  This is one reason that SCE rejected AccECN as a viable solution for closing the feedback loop in SCE at the TCP layer, it is actually ECT(1) mark counts that needs high fadelity feedback as CE rarely occurs in the SCE design (it is a backstop failure mechansim for SCE to retain ECN3168 behavior.)  We do understand that a count of ECT(1) is avaliable, but that it requires a TCP option to get at it."

AccECN is not "biased" towards L4S (it was defined a long time before L4S with ConEx and DCTCP in mind) but it simply aligns with the definition as defined in RFC3168, which defines ETC(1), as the name says ECN-capable Transport, as an alternative to ETC(0) used by the sender. SCE would change this understanding completely by using the ECT(1) mark as an alternative congestion signal to ne set in the network.

Various schemes to provide feedback have been discussed for AccECN over the years and the group decided finally to optimize for the case that is mostly deployed today (if at all), use of ETC(0) and CE only. Note that as noted by Neal recently on the list the option design is also not optimal for L4S and use of ECT(1) as client signal, however, as I replied in that thread, there are ways to extent AccECN in future and maybe e.g. provide an alternative option design.

Mirja

On 13.11.19, 15:39, "Rodney W. Grimes" <[email-masked]> wrote:

    
    Regards,
    Rod