Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

Loganaden Velvindron <loganaden@gmail.com> Tue, 05 November 2019 04:41 UTC

Return-Path: <loganaden@gmail.com>
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 73EB612003F; Mon, 4 Nov 2019 20:41:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HBHVEFGqaIic; Mon, 4 Nov 2019 20:41:28 -0800 (PST)
Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C1012002F; Mon, 4 Nov 2019 20:41:27 -0800 (PST)
Received: by mail-io1-xd42.google.com with SMTP id w12so21120307iol.11; Mon, 04 Nov 2019 20:41:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tSSS+8Iq+Bb4gojrhr9tIOlwcTpNPo7wlRsrvJZJ7xw=; b=G9LaiQ871AKCqDUq1ofaYcHl2PxwlAkWVDqkt0YGSnXXcgSIQ964Y2s8ZU9pJe1CPv EEaTzqinWEdEOoLmw8OWb5Vcg2GNCl0Ip2Vh4ZRyQ3FZg9iYjFPcgpa46yAg0a9OeiPV oZ42Of37UjEoNYNBMGcltebpandCVAg0SQHwPDy7CcnMGIMDfNzB5oc3EY8K+7svplNU nhFF+b5k1X6RvjsZMeUsEPlZCv6uDbNQwLsqegn1Vv9pfJsncEHnfm+UTW0gr3iTpPeZ FZ5XggiX3B2Q6WJc44FIGvg4bnQRYQk7CUlOZ1Wg4kmDuOij4G3xZzTq6FktUS29q+rG gH3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tSSS+8Iq+Bb4gojrhr9tIOlwcTpNPo7wlRsrvJZJ7xw=; b=GD5bVEgCJ9pAKLI6OBUEwSVPiwkO7ArbCgRiCks6VI1Jg9arF4k1smjhbsNbrYTntg mZk0QfRjjynR33NSK8i32Gn3/KzRQbqe16k3/ut9wl+2hv1jKTcQsG6U3pmZ1MKzgqT6 PvWwjTqdWhb2lb5A1tgHjUX8PLsRYu/joRPkAtORqOiokM3fIH7ilnB1214Q5JOj48Z+ H2eoWsCWboIIaGfNJrH1qcGW/bjycfdznbD8Mc4P8UEiXPW5zlCo0Mo3bhLnbSnFYKAk BZYcrpazV6BrtQ2IDgFggxh/k5M5gwr2aV6mJ0fCuOCEfkh6BeYfdt5lnE9iipoIZ0Mz V+qw==
X-Gm-Message-State: APjAAAVxbbrZheMbuJ+Gqnr2c2oapWK+XJXW+KDF/FSWyixRx/rxO6p0 fJMS3IuhBb5YgnReYHjCBQCf5Fpoz8GQOStTEAEcut9K
X-Google-Smtp-Source: APXvYqzyUM3CjD1QkWpPABwKyXC1yY6mtGMSIv4o/rz6V/MRX+Xu3HefAh/CfY4ZEWmlxuKdDWTVoHBPbKqACvaKYKY=
X-Received: by 2002:a6b:b988:: with SMTP id j130mr15182551iof.106.1572928887292; Mon, 04 Nov 2019 20:41:27 -0800 (PST)
MIME-Version: 1.0
References: <5DBFDF26.5080101@erg.abdn.ac.uk> <201911041658.xA4GwckY001605@gndrsh.dnsmgr.net>
In-Reply-To: <201911041658.xA4GwckY001605@gndrsh.dnsmgr.net>
From: Loganaden Velvindron <loganaden@gmail.com>
Date: Tue, 5 Nov 2019 08:41:15 +0400
Message-ID: <CAOp4FwRuh9y3A6aOo_yC_hbP1EUHwtMjmNF4j8zVNWezRTaDoQ@mail.gmail.com>
To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Cc: gorry@erg.abdn.ac.uk, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Jonathan Morton <chromatix99@gmail.com>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/SSL9Fr-JzYaKF_g2-OjGl8VZpRw>
Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt
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: Tue, 05 Nov 2019 04:41:31 -0000

On Mon, Nov 4, 2019 at 8:59 PM Rodney W. Grimes <4bone@gndrsh.dnsmgr.net>; wrote:
>
> > On 03/11/2019, 13:08, Jonathan Morton wrote:
> > >> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<gorry@erg.abdn.ac.uk>;  wrote:
> > >>
> > >>> With respect to draft-ietf-tcpm-accurate-ecn and
> > >>> draft-grimes-tcpm-tcpsce compatibility:
> > >>>    When accurate ecn (AccECN) fails to negotiate an AccECN capable session
> > >>>    it falls back to RFC3168 conformance, leaving a state that is fully
> > >>>    compatible with SCE, hence they are compatible.
> > >> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN?
> > > RFC-8511 doesn't change the signalling on the wire relative to RFC-3168.  That was the sense intended here.
> > >
> > >   - Jonathan Morton
> > RFC3168 describes both endpoint behaviour and network functions. To me,
> > this sentence is about
> > how you receive indications of incipent congestion, the sender can
> > change from using only CE to using CE plus
> > the accurate information -or fall back to using just CE - ultimately it
> > falls back to just detecting congestion (loss,delay).
> > So yes, the CE signal could be regarded as input to SCE.
> >
> > The endpoint behaviour, I think, should fall back to RFC8511.
>
> The response to CE of an SCE capable end-point is unaltered by
> the fact that SCE is in use.  If RFC8511 is enabled on the
> end node the response shall be that of the ABE parameters, if
> RC8511 is not enabled then the response should be that of RFC3168.
>
> IE, the 2 experiments co-exist without any special considerations,
> and SCE plays nicely with either response to CE.
>
> Explicitly stating in this draft that behavior should fall-back
> to RFC8511 would complicate implementation details as then an
> implementor may be required to implement RFC8511 if it did not
> exist, and also to some how "know" that a connection was SCE
> capable, somethng a sender is unaware of until the first ESCE
> mark is recieved, and something that can change as paths over
> the internet change during the life of the connection.
>
> Further more stating RFC8511 as a fallback position would more
> or less mandate that RFC8511 be used if SCE is used, something
> that may not be desireable.

I agree with Rod here.
>
> In summary.  tcpsce does not alter CE generation, feedback or
> response, leaving all existing RFC's intact as they are written
> with respect to the CE and ECE bits.  Tcpsce does not alter the
> response to loss either.  This is by design.
>
> > Gorry
> --
> Rod Grimes                                                 rgrimes@freebsd.org
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm