Re: [Int-area] [tsvwg] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

Jonathan Morton <chromatix99@gmail.com> Sat, 27 July 2019 12:50 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD2A1202C4; Sat, 27 Jul 2019 05:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 EsGZR6bh4VC3; Sat, 27 Jul 2019 05:50:20 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 E52371202C0; Sat, 27 Jul 2019 05:50:19 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id a15so55305123qtn.7; Sat, 27 Jul 2019 05:50:19 -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=76UUIPhatGW8Lzvo0RLq4m6Brn97TbWacvOYskYzqug=; b=cjc8KUsrfaDg4Bh/SFknaqy/D6qft6p3GFQ43kFcdbf14wjIqw5dU9Ec5wAVYAajFS 2JODBJopwc1t64dX0nScUgHqo4mtCUqOkn48vdf6pFyPcLKdpdfLJY1gtewqMAtUEhsO Rm2zW2o3N3H+aprhyj5fnuzCjgakH9c5MTbWth7BKA4tGQAz16yPMNHwQh2n85OaG/++ 2dBYI67gjzhq0lOH9cec/HN7QklMDQcivuXNU3IJxCw7c8gnstcjIGYJtaIaAsaAvnjY dxHQUatTe8nstXDSvjwY2GF9Z6ieaItR7YLbfUZOcVyxqorX3oowWCav0wPJYxBmPnHH Zz/w==
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=76UUIPhatGW8Lzvo0RLq4m6Brn97TbWacvOYskYzqug=; b=CozUML3gJzQTHdwXEir691RIT2dAQhVeTB7IH3AOqXs5SgMpQV7CHqz/6v9qKjk8Lj 0JsmLhPeZHtwoQBVUygossrP/DLqP9Zio3alZeV0ufCqcKLK7Ua/8c5l0ZP1uNZmw3Oj nTWPMH9RzDmsZA1jXoPgisufxXDxiDR6cha2IxknMGgcDNSKsqJ/H9wMsfUfYndLVVxK SVnP21Psj95NG0FCOvYlgi2+8Gr2hO9PNWozfUP6Bo5NqRwgxnFV4OPYCpUIR7M5biid Xoqj5v3v20pPOqs53p0vCb29v2in7d+vBf141nzCpzP6V1JPAspsdPJxVFl1EJLFYTkK xdmw==
X-Gm-Message-State: APjAAAX2MuLm2GIPUI+H5Hx3E23+dgzNY+2y9i1LXGCn8AiRRurlYQZk ryisvhJDkkTXBzxTHquQs0u6aFSqDWk=
X-Google-Smtp-Source: APXvYqwoUTqCmyJ/s2H4F9TJWT0LnTu5/YRLq7blmKQt0Lo4Q02eFaYig7edLSPX0vvfaBOp6kRRzw==
X-Received: by 2002:a0c:f909:: with SMTP id v9mr72116209qvn.83.1564231818622; Sat, 27 Jul 2019 05:50:18 -0700 (PDT)
Received: from jonathartonsmbp.lan (173-246-8-242.qc.cable.ebox.net. [173.246.8.242]) by smtp.gmail.com with ESMTPSA id z1sm28417296qkg.103.2019.07.27.05.50.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jul 2019 05:50:17 -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: <f62fcf13-0486-a2ca-1f41-088cfff12d8e@bobbriscoe.net>
Date: Sat, 27 Jul 2019 08:50:15 -0400
Cc: Joe Touch <touch@strayalpha.com>, "Black, David" <David.Black@dell.com>, "int-area@ietf.org" <int-area@ietf.org>, tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A597CFA4-1A8B-42DC-B37E-B3F75F9FECC0@gmail.com>
References: <CE03DB3D7B45C245BCA0D243277949363052958E@MX307CL04.corp.emc.com> <598B8434-3B6D-434A-B963-7FEE04D9770B@strayalpha.com> <70abde72-0091-66e3-b819-ad839e1fd028@bobbriscoe.net> <d7252ffe-e13c-243c-efa2-bb15e67bd758@bobbriscoe.net> <DA78B7A6-92FB-4BCB-A74A-DF53ED722714@gmail.com> <f62fcf13-0486-a2ca-1f41-088cfff12d8e@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/BXo3gH2AsSysOClOubWSs5SkNwg>
Subject: Re: [Int-area] [tsvwg] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jul 2019 12:50:22 -0000

> On 27 Jul, 2019, at 6:01 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Yes, with byte-preserving, as packets are re-assembled the number of marked packets reduces. Counter-intuitively, that's correct, even for compatibility with TCP's single congestion response per RTT.
> 
> I originally suggested the requirement in RFC3168 to preserve the number of marked packets, but it's incorrect. It's not compatible with TCP's single response per RTT (or the response to the proportion of marks of other TCP-Friendly real-time congestion controls).
> 
> This is not a matter of compatibility with just one of SCE or L4S. The logical OR approach is wrong for both, and the byte-preserving approach is correct for both - see previous response to Markku.
> 
> Reasoning: the paramount requirement when reassembling fragments is to reconstruct the marking probability that would have occurred had the packets not been fragmented when the AQM in the tunnel marked them. The logical OR approach increases the marking probability as if congestion was higher, while byte-preserving keeps it constant.

I think you are still thinking in terms of marking *probability*, which is not correct in at least conventional RFC-3168 semantics.  Conventional TCPs are sensitive to the number of RTTs between marks; the DCTCP response function is sensitive to the number of marks per RTT.  Both are *time based* relationships.

Codel, the most deployed AQM, is a *time based* marking function.  Preserving the marking probability while the number of packets decreases would reduce the number of RTTs containing a mark.  The original logical-OR function correctly preserves this property, and only fails when there's a mixture of ECT(0) and ECT(1) marks on fragments for a single packet (which can legitimately happen with SCE but not L4S, ironically enough).  Preserving the number of marked bytes does not preserve the number of marks over time, and therefore does not preserve the intent of the marks applied by the AQM.

That's the logic behind my suggested series of rules.  I carefully held both L4S and SCE requirements in mind, as well as those of RFC-3168, while drafting them.

 - Jonathan Morton