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

Bob Briscoe <ietf@bobbriscoe.net> Thu, 25 July 2019 20:27 UTC

Return-Path: <ietf@bobbriscoe.net>
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 BD562120276; Thu, 25 Jul 2019 13:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=bobbriscoe.net
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 8aJD7z656CLN; Thu, 25 Jul 2019 13:27:23 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1390120279; Thu, 25 Jul 2019 13:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bDd6tiwC9rJ8PiN5t67Is0YpX1/gH9eZHo7ceDWvYVQ=; b=x2BNxfKrf2F/fT5FEiDIjPWPTQ 1ST0Tyc3BhwqI+sKDWDOrDCmg7iTiASqMCUN0DCsJiitcv9GmkMlUzybUUcr6n9/ZXF/tji6RMvj+ gomiqqNuMrYeoGW7/PBCG6C1kwYRL6Ba9JfmVV4YZlSLO8Zan677c2CgQh2q628DpQAIbRrAjxhdz Le9xHygVvC85h5d8V2q6+h+Y86JYZkUkFShXr8++NZ0oZ3Thkd8uxT/LsW0AUBA+kveoyJKtAm8Gv HqGsYLeQTNyAHVQgQguAvh3jyKzyBHlwWL+Zl31dLyaCm9ttnySyPlA9Bu+v5lZENmbrueVw1bXoF GMh4LhEg==;
Received: from dhcp-9572.meeting.ietf.org ([31.133.149.114]:51306) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1hqkKe-0006Qc-UE; Thu, 25 Jul 2019 21:27:21 +0100
To: Jonathan Morton <chromatix99@gmail.com>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <201907121939.x6CJdlp7060765@gndrsh.dnsmgr.net> <e1530080-ee6c-78d9-4be3-61d9ab8abe76@bobbriscoe.net> <89B2FD3D-4C10-489A-9867-538BABF3E521@gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <80a6f25b-9bb7-2812-eccb-15cc06772ab7@bobbriscoe.net>
Date: Thu, 25 Jul 2019 16:27:19 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <89B2FD3D-4C10-489A-9867-538BABF3E521@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/V5SzFir-IdErGb_DsQGf046DZn8>
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 20:27:31 -0000

Jonathan,

On 25/07/2019 14:53, Jonathan Morton wrote:
>> 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.
As you say, AccECN does support SCE - with the option. That was because 
it was generally agreed that accuracy of the CE signal was paramount, 
rather than trying to do two things with 3 bits and under-achieving for 
both.

We did have another scheme with 5 & 3 codepoints in the 3 bits for two 
counters - look back over the draft history. But the WG decided 
simplicity was also important in a CC protocol, cos lack of bugs is also 
important.
>   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.
You will find there is resistance to starting to use the NS flag after 
having negotiated RFC3168 ECN feedback, but without any explicit 
negotiation. You will probably be asked how a future experiment would be 
able to use the NS flag if your experiment fails (assuming it is adopted 
as IETF work in the first place). You are walking into a world of bit 
scarcity.

>
>> 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.
My point wasn't so much about safety, it was about about accuracy and 
particularly biased error. The essence of low latency congestion control 
is keeping the queue low without losing utilization, which requires 
accuracy. If your feedback has a biased but unknown error, it's really 
hard to accurately converging towards a target.

>
> 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.
Exactly - if your feedback has a biased error, you will usually miss the 
target and try again in the next round. No point continuing this 
discussion - I'm just saying you'll need to see what happens in reality 
when the feedback is thinned.


Bob

>
>   - Jonathan Morton
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/