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

"Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Wed, 13 November 2019 14:39 UTC

Return-Path: <4bone@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1FD12080A for <tcpm@ietfa.amsl.com>; Wed, 13 Nov 2019 06:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAgDzeWbyOih for <tcpm@ietfa.amsl.com>; Wed, 13 Nov 2019 06:39:10 -0800 (PST)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55EE12003E for <tcpm@ietf.org>; Wed, 13 Nov 2019 06:39:09 -0800 (PST)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id xADEd5ce044223; Wed, 13 Nov 2019 06:39:05 -0800 (PST) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id xADEd4Kv044222; Wed, 13 Nov 2019 06:39:04 -0800 (PST) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201911131439.xADEd4Kv044222@gndrsh.dnsmgr.net>
In-Reply-To: <F4F44758-691A-40A2-95FF-060ECDA6FEAA@ericsson.com>
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>
Date: Wed, 13 Nov 2019 06:39:04 -0800
CC: Yoshifumi Nishida <nsd.ietf@gmail.com>, "tcpm@ietf.org" <tcpm@ietf.org>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/pqSqr2h0iDjQKwCrso8EOi3EjGQ>
Subject: Re: [tcpm] Seeking feedback for draft-ietf-tcpm-accurate-ecn and draft-ietf-tcpm-generalized-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Nov 2019 14:39:12 -0000

Hello Mirja, Yoshi, etc al,

Some comments in line (marked with [RWG]

Regards,
Rod

> Hi Yoshi,
> 
> see some comments in line (marked with [MK]).
> 
> Mirja
> 
> From: Yoshifumi Nishida <nsd.ietf@gmail.com>
> Date: Wednesday, 13. November 2019 at 09:09
> To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
> Cc: Pete Heist <pete@heistp.net>, "tcpm@ietf.org" <tcpm@ietf.org>
> 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 <mirja.kuehlewind@ericsson.com<mailto:mirja.kuehlewind@ericsson.com>> 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.

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

> 
> 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).

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

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

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

> 
> 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?

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

> --
> Yoshi
> 
> 
> 
> 
> 
> On 08.11.19, 09:23, "tcpm on behalf of Pete Heist" <tcpm-bounces@ietf.org<mailto:tcpm-bounces@ietf.org> on behalf of pete@heistp.net<mailto:pete@heistp.net>> 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 <nsd.ietf@gmail.com<mailto:nsd.ietf@gmail.com>>
>     > 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
>     tcpm@ietf.org<mailto:tcpm@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
Rod Grimes                                                 rgrimes@freebsd.org