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

[Yoshifumi Nishida <[e-mail]>]

Hi Mirja,

Thanks for the response.

On Tue, Nov 12, 2019 at 8:30 AM Mirja Kuehlewind <
[e-mail]> 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



>
>
>
> On 08.11.19, 09:23, "tcpm on behalf of Pete Heist" <[e-mail]
> on behalf of [e-mail]> wrote:
>
>     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 <[e-mail]>
>     > 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
>
>     _______________________________________________
>     tcpm mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tcpm
>
>
>