From nobody Fri Oct 30 11:43:03 2020 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9634F3A1111; Fri, 30 Oct 2020 11:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 tTl149Xl94mq; Fri, 30 Oct 2020 11:42:57 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 C7AE33A110F; Fri, 30 Oct 2020 11:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:MIME-Version:Date:Message-ID:Cc: To:Subject:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6xA+nTzaN5LFDK7VVa52uyDsSq/QSIPJmpsYsFJn8Ic=; b=DYU6GgU0g6/uZbSh4brJqplzoS 2DPYGcdZKcZYC2VfBQhWzg1s2TL0x5HdMirSnx2edYrfTnks/8NAwP+1ylTf3WT59e2IlH5ieNvR+ MDryB8NuhLql/tbU9vdOkQT7JrHkUGmwqn+NLMgItpfIZCCIQc4X/APhj3W2AuP9AUCPsx0DRNdU7 mrjLLSbWDFvTpp+TVPxJ35jHbI/f8qOgj94ij+x50TyiwHI+ycZlUPftTMp8XQoKUBNJrVMa0KEQd P0mRZk8SJLSIcRP3/XwKnOqV4iUsYZwbG8/M13eNoXQA3pYGBVBhb0u5F51aV2fR+LzirjAliBQbT i3NO4mlg==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:58836 helo=[192.168.1.3]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kYZMR-00Ad0f-LY; Fri, 30 Oct 2020 18:42:51 +0000 From: Bob Briscoe To: tsvwg IETF list Cc: TCP Prague List , iccrg IRTF list , "De Schepper, Koen (Koen)" Message-ID: Date: Fri, 30 Oct 2020 18:42:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7047358348D05B4037AB2E1C" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net 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: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [tcpPrague] ecn-l4s-id: Proposed Changed to Normative RTT Bias Text X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 18:42:59 -0000 This is a multi-part message in MIME format. --------------7047358348D05B4037AB2E1C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Folks, The co-authors of ECN L4S ID have been reviewing the correctness of the normative 'Prague' requirements.     See https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3 This is the first of 2 emails, about 2 of the requirements that we think ought to be reworded a little. If you agree with the rationale, but think the new wording still doesn't capture the requirement well, pls suggest sthg better. If you disagree with the rationale, pls discuss. 4.3. Prerequisite Congestion Response ... CURRENT: o A scalable congestion control MUST reduce or eliminate RTT bias over as wide a range of RTTs as possible, or at least over the typical range of RTTs that will interact in the intended deployment scenario (seeAppendix A.1.5 for rationale). PROPOSED: A scalable congestion control MUST eliminate RTT bias as much as possible in the range between the minimum likely RTT and typical RTTs expected in the intended deployment scenario  (see Appendix A.1.5 for rationale). RATIONALE: 1/ "eliminate as much as possible" is stronger than "reduce or eliminate". 2/ This requirement was motivated by 'do no harm to others' relative to existing standard (RFC5681 Reno) congestion control. So there is no need to mandate that an L4S implementer does no harm to themselves, which window-based congestion controls tend to do at higher RTT. Of course, this doesn't preclude implementers reducing or eliminating RTT bias for larger than typical RTTs, but it removes any requirement to do so. Cheers Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------7047358348D05B4037AB2E1C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

The co-authors of ECN L4S ID have been reviewing the correctness of the normative 'Prague' requirements.
    See https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-10#section-4.3
This is the first of 2 emails, about 2 of the requirements that we think ought to be reworded a little.

If you agree with the rationale, but think the new wording still doesn't capture the requirement well, pls suggest sthg better.
If you disagree with the rationale, pls discuss.

4.3.  Prerequisite Congestion Response
...
CURRENT:
   o  A scalable congestion control MUST reduce or eliminate RTT bias
      over as wide a range of RTTs as possible, or at least over the
      typical range of RTTs that will interact in the intended
      deployment scenario (see Appendix A.1.5 for rationale).

PROPOSED:
A scalable congestion control MUST eliminate RTT bias as much as possible in the range between the minimum likely RTT and typical RTTs expected
in the intended deployment scenario  (see Appendix A.1.5 for rationale).

RATIONALE:
1/ "eliminate as much as possible" is stronger than "reduce or eliminate".
2/ This requirement was motivated by 'do no harm to others' relative to existing standard (RFC5681 Reno) congestion control. So there is no need to mandate that an L4S implementer does no harm to themselves, which window-based congestion controls tend to do at higher RTT. Of course, this doesn't preclude implementers reducing or eliminating RTT bias for larger than typical RTTs, but it removes any requirement to do so.

Cheers


Bob

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