Re: [tcpm] Tech review of draft-grimes-tcpm-tcpsce-01.txt

Jonathan Morton <chromatix99@gmail.com> Fri, 15 November 2019 23:28 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 630C8120044; Fri, 15 Nov 2019 15:28:56 -0800 (PST)
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 a0jgmOe-dmWI; Fri, 15 Nov 2019 15:28:55 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 D86F2120033; Fri, 15 Nov 2019 15:28:54 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id j12so5699107plt.9; Fri, 15 Nov 2019 15:28:54 -0800 (PST)
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=NLyJC70St3504OD7sWR7b40qV7nIUalmjUSo0XATMBI=; b=qYYDq+vwp5pwqvUp9JWV46pX1/aD8+wdA/G0FE0Xw2hmhNAWE7oL7WjVoI/0uO/bLc haCNy2+CRR1Dcuj+kDvjjss+/OsI//O41Z567xVMkUmsTTBbrdAEkbnt3VrPMxzTJDEo ruEXuAv+4+Teq/MFvF90xcWahTNLneS9O6kpWenf+ZDDM2idibShgMyPyCxgRBB/97PA OELDR1SAjMVFvJZ6tPwu51UJI1U4OIrvAZEWEDnOHFDCcNiDPT5rRWRoSeLbYRjzgu9j J1OBh8lRsLQ/01JKmxmvw/cJcNjlcZfloMMjHyqZY7XtkJcAYfKZ2PeFsgYDrRQecVnw KVGw==
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=NLyJC70St3504OD7sWR7b40qV7nIUalmjUSo0XATMBI=; b=F7byA2irCG84wQTBOD0J/bP0H8jW1pF8OHiaGmVF28h19B8GSv2zbOZOOFOQY6jEXy cEcb4Mg+uAlizQViIbM2DuGM+UXn6wleESNxRUU79j0ICdZmr8RUMJJ2n3iEKu9p5yqz 8PP6HjBKX7rqwvq/mxS1seHdJG3uYU/EjFRGvtyKjDBanp2x/m1gSen1d8EOsPqsiNv8 AvEr7s/ZezYCgduTTQM4G1RMMiLxQvgMrIGs7Z6FWO5i2QqItahWot/wetQv36BW9ueT CVkFxTVS3T1PjR/hNZ3iOTbo/efsH46X8Cqi7ChsBRG6+73KHDbn0LjjL/slT1aWXv8U ksKw==
X-Gm-Message-State: APjAAAXK6F7E7Pe1aroIpk1klim4kCZlN9/Ip8+JmMM8+u32WiQDzzrn YgRHUINatr++coQLCspHRqw=
X-Google-Smtp-Source: APXvYqwjo71dWpUfX+J5Rm8FUpWIvxWJ5agpKcHNlQP3Fkj0+29+032+xQvMvfgrc3WdC7zCVZenpA==
X-Received: by 2002:a17:902:d891:: with SMTP id b17mr17697736plz.308.1573860534215; Fri, 15 Nov 2019 15:28:54 -0800 (PST)
Received: from jonathartonsmbp.lan ([182.55.197.52]) by smtp.gmail.com with ESMTPSA id s23sm10998817pgh.21.2019.11.15.15.28.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Nov 2019 15:28:53 -0800 (PST)
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: <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net>
Date: Sat, 16 Nov 2019 07:28:50 +0800
Cc: rgrimes@freebsd.org, tcpm@ietf.org, draft-grimes-tcpm-tcpsce@ietf.org, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FB1D6B3-7995-473B-8055-C222BE19427A@gmail.com>
References: <201911042204.xA4M4Zob002799@gndrsh.dnsmgr.net> <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/8ifYoLd0W2gQvAED9cZ1HfRuaGU>
Subject: Re: [tcpm] Tech review of draft-grimes-tcpm-tcpsce-01.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, 15 Nov 2019 23:28:57 -0000

> On 16 Nov, 2019, at 1:59 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Why go through all the years of pain of altering the TCP wire protocol for an accurate feedback scheme that isn't accurate?

Without delving into the rest of the detail right now, I'd like to address this point immediately.

Congestion control is, ultimately, a system with a control loop under negative feedback.  When designing such a control loop, one is generally concerned with whether it has sufficient gain to converge on the appropriate setpoint, and is acceptably stable.  The nature of the feedback path feeds into that analysis, but as long as the result meets acceptability criteria, a simpler control system is often preferable.  One fundamental property of a negative-feedback system, though, is that the system returns towards the setpoint after a disturbance, even that disturbance occurred *in* the feedback path.

Consequently, SCE can tolerate as much as 100% relative error in the SCE feedback path.  The case of being 100% low - no ESCE feedback received at all - corresponds to falling back to RFC-3168 compliant behaviour, ie. the MD response to CE acts as a ceiling on the positive excursion of the control output (cwnd).  The case of being 100% high - twice as much ESCE feedback received as SCE marks were applied on the forward path - will cause a low excursion which will drain the affected queue, after which SCE marking will stop, and the system will then recover.

Consequently we made the design decision that *reliable* accurate feedback was not necessary, nor was the associated complexity desirable.  We also observed that a single additional bit per received segment was always adequate to convey *accurate* feedback, and that usually fewer bits were needed, which fits well with using one spare bit per Delayed ACK packet - which is what we do here.  Several such bits are available in the TCP header for such uses, and we decided to recommend the use of one which had recently been freed up and whose previous use was closely related.

Without yet having examined your other arguments in detail, I suspect you are misunderstanding how some of our proposed feedback methods work in practice, perhaps stemming from the above fallacy.  Understand that we have actually implemented each of these methods in running code, and can demonstrate their operation at the Hackathon.

See you there.

 - Jonathan Morton