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

Jonathan Morton <chromatix99@gmail.com> Fri, 12 July 2019 18:10 UTC

Return-Path: <chromatix99@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 53F2D120802; Fri, 12 Jul 2019 11:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.453
X-Spam-Level:
X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wkJBkQgc2NGL; Fri, 12 Jul 2019 11:10:29 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 4ED8C1207FD; Fri, 12 Jul 2019 11:10:17 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id p17so10219922ljg.1; Fri, 12 Jul 2019 11:10:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lWTh7FWUu2P0DIbCMB3WRpP/7ZoGa8NX89vVpQ+bBM0=; b=arMpPszuzUWP6meDgTJvLWd4sEU0MF3STnyQHKhWBNsSMVxMeAProkrIsjuUiO1BKb VjhrLQ7lnXwM+gnpsneYqZB1W7kxVy1HlQ6z/uu+DriBC+pdkuRrJJ8pvs5idJb64L5X ry+1U8r7VBg03+6CqZBJao/NmWk1VzaUjqG1WQCY0EMaw2psMlNEiROYCLPBiPgSSIo4 fsNpXwgPOuubz0TLqur78XxGqDS83hUM3qXl5oetDjbkFUIAwpTDDV50FsxJZz/f8cLx ggWG39VGKCkLFXHRe/lSpPRqVQ8rJOLi9mtW9sxivUqEopfX5GzChagQ/yp6iMbOd4W+ CyYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lWTh7FWUu2P0DIbCMB3WRpP/7ZoGa8NX89vVpQ+bBM0=; b=L/6RrkWVsy2fnEt+htHuHvUHec+fh4xQAcu6jA9tO5xb9NOUrIgOdJUHZ0woxEWWeg ErIt7ot/4GreWx1ZtaKKv8NoD/rmmQg57ZDfC8XeiO0LHKnbJa/PxHysrxkjAcsmqOIn Kb1PKX/IgjHSpLc4b9xjbhR9K7TCykMVJ3u+GSxU4BIgFgQ5kjDWqUwP51yyrvZ+uePl GLYHAeZo+vouGYr/9rnHwAfot/fO29poHb2cNZQv26uxZWlPgOg1OsiRpRWVAW44Y9xX Lu79nmZmbe4WusUi7S9HDDszLDBcCv+rRy7KCe0Sn2/4ZWfZdm6GYMd/iWYfFdfjNQKS 92Kg==
X-Gm-Message-State: APjAAAWmU/ErcxsxnSDU64pXa6zUYL5q4XqVSLlHWuoLMsIKMegdcCLA A/LsXjr1Nl9d6vUQ6kJDowc=
X-Google-Smtp-Source: APXvYqx04jDjs+s7e5RvL6r1HHQqRePIPdWC1QO0juMPdJZbQ9oWI6Genk+XbjSCvc1b/OfY8MB1Tw==
X-Received: by 2002:a2e:87d0:: with SMTP id v16mr6817681ljj.24.1562955015374; Fri, 12 Jul 2019 11:10:15 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-234-41-nat-p.elisa-mobile.fi. [83.245.234.41]) by smtp.gmail.com with ESMTPSA id f10sm1191066lfh.82.2019.07.12.11.10.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jul 2019 11:10:14 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D2432779493630615D38@MX307CL04.corp.emc.com>
Date: Fri, 12 Jul 2019 21:10:12 +0300
Cc: "rgrimes@freebsd.org" <rgrimes@freebsd.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABFB2F9C-F2EF-4DF7-AB6A-7CD3DA3767A2@gmail.com>
References: <201907090007.x6907J5B040088@gndrsh.dnsmgr.net> <CE03DB3D7B45C245BCA0D2432779493630615D38@MX307CL04.corp.emc.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/izuO8iMAB6OYHx87vXrUdmQHlXU>
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: Fri, 12 Jul 2019 18:10:31 -0000

> On 12 Jul, 2019, at 8:18 pm, Black, David <David.Black@dell.com>; wrote:
> 
> As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. 

We did look into this, but found some shortcomings that simple reuse of the NS bit (or assigning one of the other spare TCP header bits adjacent to NS) neatly overcomes.

First is that much of AccECN is focused on providing accurate feedback of CE marks, which is not very relevant to SCE since the existing ECE/CWR mechanism from RFC-3168 works well.  For this purpose the NS bit is also consumed, forming a 3-bit field that straddles a byte boundary and is thus awkward to parse.

A simple transformation of this field into one that counts SCE marks doesn't work, because feedback of CE marks is then lost.  Retaining the original response to purely CE-based congestion feedback is a crucial part of SCE's design for incremental deployment.

To get feedback of ECT(1) which carries the SCE information, the full length of the AccECN TCP Option must be used, inflating the volume of the ack stream - and concerns have been raised about TCP Options in discussions here.  A similar concern made one of our other ideas (replacing TCP Timestamps with a slight larger option that would absorb the NOP padding currently used) less desirable, though that also avoided the ack-inflation problem.

We therefore tried to explore ideas that posed minimum risk of confusing firewalls or increasing software complexity.  We considered that reusing a bit that had previously been assigned to an ECT(1) related mechanism would be safest, and subsequently found that it could convey all the information needed with sufficient reliability.

I agree that this draft could be improved to explain the above choice and give more detail on the expected semantics.  I'll work with Rod to sort that out.

 - Jonathan Morton