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

Jonathan Morton <chromatix99@gmail.com> Thu, 25 July 2019 18:53 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 32C3D1201E9; Thu, 25 Jul 2019 11:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 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, 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 k-uwV6NV-80F; Thu, 25 Jul 2019 11:53:48 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 908AC120191; Thu, 25 Jul 2019 11:53:48 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id m23so34415190vso.1; Thu, 25 Jul 2019 11:53:48 -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=TvszhvUR4ndmu5p7GvuMIfOhk5j4UgWxqRGe3davLaE=; b=jB1QHYexjiPQCoPQcUssXfTRHFdbLKatxuudvrD65tKslgHz3RGRpAHvFNm0/zwbJ6 VHQCKhPGr2qZC7JQT54SWvZNcC7iBL1xq5EmQ+ZJpI/tj7mcJnqDF9fwKAGyywUGDPrJ JMWcBg1q3fXuBmadEfGuCQDm/tf4zpr4gZW42pICov3+559YQZWaaUYeQb68uLUxRpA0 Hq8HFdZO0k3tU8NPINMHuurvK+fVOvDJquu4/Burmze/Tv1cwMMRJyX8g2jojQCbMcTG kf6/rwLl7E6R5VctNcY3cDWjvI9m+QD3t1phfS8C/eP8SC2hkYKL8LHsvZJSrR7zMYjA Ip1w==
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=TvszhvUR4ndmu5p7GvuMIfOhk5j4UgWxqRGe3davLaE=; b=lVoiQe71Uc+T0pxPW7gs0I4ShHf7E2wCOIK1DcFtIPxArI4XWZCTtb2mq93gli8NLt C5PSz9XLDRUZxkKMQBcrUZh9D/YTQbKSwkZ8LVP1RTQqaHvYfBS3aq8CeiTq6x1hpZhn MuZ5jsnKH8WucFD4Uh4CxRaMG3JxTo/oDMjA81P2vD3kVbQHIVLgAXjoP0nSnckqRNcl yqr/S/Hs3MEZrHN4KEXsEPXCBUj/OAjivwNQr/CzJRdYrO1RhYW/dNBc8f15vFy6hbeD YEz8xRong98ZRmYSVeHtmUNEKNlv91qQb2Ft8uhvMCWEakfPveiu/mZECgc8owcE8mA+ h4Wg==
X-Gm-Message-State: APjAAAU7GQpyP4gV/LGBXzVbZj6mcdROdrOoQ4pQZ7WwmaAhKazggDpK OFRuqzHp2c8X0T2XPQj5P/iAEZCF
X-Google-Smtp-Source: APXvYqwdVqcVwPz0EBJZ/g1D59o+PtixhnBooHndaV8MEFyxchspBKFqqlNo4VDZaPqvv0dHwXV6MA==
X-Received: by 2002:a67:b14c:: with SMTP id z12mr54165251vsl.11.1564080827602; Thu, 25 Jul 2019 11:53:47 -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 f140sm35957849vka.36.2019.07.25.11.53.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 11:53:46 -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: <e1530080-ee6c-78d9-4be3-61d9ab8abe76@bobbriscoe.net>
Date: Thu, 25 Jul 2019 14:53:45 -0400
Cc: rgrimes@freebsd.org, "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <89B2FD3D-4C10-489A-9867-538BABF3E521@gmail.com>
References: <201907121939.x6CJdlp7060765@gndrsh.dnsmgr.net> <e1530080-ee6c-78d9-4be3-61d9ab8abe76@bobbriscoe.net>
To: Bob Briscoe <in@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Saqulea6LPPpWF1cpX49_hOAqkw>
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: Thu, 25 Jul 2019 18:54:00 -0000

> On 25 Jul, 2019, at 2:20 pm, Bob Briscoe <in@bobbriscoe.net>; wrote:
> 
> The idea was to have a generic wire protocol with a dumb receiver, so that the same feedback protocol could support multiple needs for feedback by different TCP congestion control algorithms.
> 
> So a fairly inefficient re-use of the 'NS' TCP header flag for one particular experiment is very unlikely to fly, particularly when the experiment it supports doesn't satisfy all the requirements in 7560.

AccECN burns the same bit to provide higher fidelity feedback of CE, without addressing our need to feed back the distinction between ECT(1) and ECT(0) at all (unless the TCP Option is used).  Since higher fidelity feedback of CE is not useful for SCE, using NS in this way is actually more efficient for us.  Happily, AccECN and SCE can coexist on different flows, thanks to the fact that AccECN does have a negotiation phase which SCE can naturally reject.

> For instance, I think the reason the tcpsce draft discusses multiple ways of doing the feedback is that, in the presence of pure ACK loss (which is often due to deliberate ACK thinning), none of the three solutions preserve reliable delivery of the ACK signal.

In SCE, *reliable* feedback of SCE signals is not actually required, both because the control loop is naturally stable, and because RFC-3168's CE feedback *is* reliable and thus offers a safe fallback.  Of course we understand that the design constraints for L4S' feedback mechanism were different.

Ack thinning is also something we have explicitly considered, given that Cake includes an optional ack-filter which does exactly that.  (We have, for example, added consideration of the NS bit to Cake's ack-filter, which was a trivial patch.)  Mathematically, the most extreme errors possible in either direction, due to ack thinning, are easily corrected during subsequent RTTs.

 - Jonathan Morton