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

[Mirja Kuehlewind <[e-mail]>]

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" <[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