From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 lists.bufferbloat.net (Postfix) with ESMTPS id 9E4083CB43 for ; Sun, 21 Jul 2019 15:14:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding: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=p/wYng7/mEiA69ob31kvndvqOB7mGUH2Ucc+LzWlsfA=; b=dEx9Ll2oyHUoSYiDT75nsdG3f JJVZ2z6f76Xyvn2YRKnRdU1YJl7h3OiutezS/pfuybt8AVKfaSdiksBOLIdGZ52SaDYPKHxE033Yf JajKZBwTsSygAwtzj/bqrigwoXPA0EBk3tQCjq9hSczB8UVF0iGJl5wf24y9OHAiLL6F5sx++yrhF RGMCvJVb+QYk+6OmkXYa3vRhZnz6BcdHHpmbXTUHPK91NW3mXDLkv0AZJ+ztcuXXdRv19YCefDXy3 mMlWDnM0WyoaJEEiN+teg1MLCeyIhe282J0a37QQzjv+P2WWs7uI9Wh1nANOy+FgT9TDeOlF+YMZR 1wH2ybDdw==; Received: from dhcp-819f.meeting.ietf.org ([31.133.129.159]:51776) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1hpHHs-0005AC-7U; Sun, 21 Jul 2019 20:14:24 +0100 To: Sebastian Moeller Cc: "tsvwg@ietf.org" , "Black, David" , "ecn-sane@lists.bufferbloat.net" , Dave Taht , "De Schepper, Koen (Nokia - BE/Antwerp)" References: <364514D5-07F2-4388-A2CD-35ED1AE38405@akamai.com> <1238A446-6E05-4A55-8B3B-878C8F39FC75@gmail.com> <17B33B39-D25A-432C-9037-3A4835CCC0E1@gmail.com> <52F85CFC-B7CF-4C7A-88B8-AE0879B3CCFE@gmail.com> <87ef2myqzv.fsf@taht.net> <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> From: Bob Briscoe Message-ID: <34e3b1b0-3c4c-bb6a-82c1-89ac14d5fd2c@bobbriscoe.net> Date: Sun, 21 Jul 2019 20:14:22 +0100 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: <4B02593C-E67F-4587-8B7E-9127D029AED9@gmx.de> Content-Type: multipart/alternative; boundary="------------E94CFB6364A0DE67C00EB4B8" 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 - lists.bufferbloat.net 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 Subject: Re: [Ecn-sane] [tsvwg] Comments on L4S drafts X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2019 19:14:27 -0000 This is a multi-part message in MIME format. --------------E94CFB6364A0DE67C00EB4B8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sebastien, On 21/07/2019 17:08, Sebastian Moeller wrote: > Hi Bob, > > >> On Jul 21, 2019, at 14:30, Bob Briscoe wrote: >> >> David, >> >> On 19/07/2019 21:06, Black, David wrote: >>> Two comments as an individual, not as a WG chair: >>> >>>> Mostly, they're things that an end-host algorithm needs >>>> to do in order to behave nicely, that might be good things anyways >>>> without regard to L4S in the network (coexist w/ Reno, avoid RTT bias, >>>> work well w/ small RTT, be robust to reordering). I am curious which >>>> ones you think are too rigid ... maybe they can be loosened? >>> [1] I have profoundly objected to L4S's RACK-like requirement (use time to detect loss, and in particular do not use 3DupACK) in public on multiple occasions, because in reliable transport space, that forces use of TCP Prague, a protocol with which we have little to no deployment or operational experience. Moreover, that requirement raises the bar for other protocols in a fashion that impacts endpoint firmware, and possibly hardware in some important (IMHO) environments where investing in those changes delivers little to no benefit. The environments that I have in mind include a lot of data centers. Process wise, I'm ok with addressing this objection via some sort of "controlled environment" escape clause text that makes this RACK-like requirement inapplicable in a "controlled environment" that does not need that behavior (e.g., where 3DupACK does not cause problems and is not expected to cause problems). >>> >>> For clarity, I understand the multi-lane link design rationale behind the RACK-like requirement and would agree with that requirement in a perfect world ... BUT ... this world is not perfect ... e.g., 3DupACK will not vanish from "running code" anytime soon. >> As you know, we have been at pains to address every concern about L4S that has come up over the years, and I thought we had addressed this one to your satisfaction. >> >> The reliable transports you are are concerned about require ordered delivery by the underlying fabric, so they can only ever exist in a controlled environment. In such a controlled environment, your ECT1+DSCP idea (below) could be used to isolate the L4S experiment from these transports and their firmware/hardware constraints. >> >> On the public Internet, the DSCP commonly gets wiped at the first hop. So requiring a DSCP as well as ECT1 to separate off L4S would serve no useful purpose: it would still lead to ECT1 packets without the DSCP sent from a scalable congestion controls (which is behind Jonathan's concern in response to you). > And this is why IPv4's protocol fiel/ IPv6's next header field are the classifier you actually need... You are changing a significant portion of TCP's observable behavior, so it can be argued that TCP-Prague is TCP by name only; this "classifier" still lives in the IP header, so no deeper layer's need to be accessed, this is non-leaky in that the classifier is unambiguously present independent of the value of the ECN bits; and it is also compatible with an SCE style ECN signaling. Since I believe the most/only likely roll-out of L4S is going to be at the ISPs access nodes (BRAS/BNG/CMTS/whatever) middleboxes shpould not be an unsurmountable problem, as ISPs controll their own middleboxes and often even the CPEs, so protocoll ossification is not going to be a showstopper for this part of the roll-out. > > Best Regards > Sebastian > I think you've understood this from reading abbreviated description of the requirement on the list, rather than the spec. The spec. solely says: A scalable congestion control MUST detect loss by counting in time-based units That's all. No more, no less. People call this the "RACK requirement", purely because the idea came from RACK. There is no requirement to do RACK, and the requirement applies to all transports, not just TCP. It then means that a packet with ECT1 in the IP field can be forwarded without resequencing (no requirement - it just it /can/ be). This is a network layer 'unordered delivery' property, so it's appropriate to flag at the IP layer. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------E94CFB6364A0DE67C00EB4B8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Sebastien,

On 21/07/2019 17:08, Sebastian Moeller wrote:
Hi Bob,



On Jul 21, 2019, at 14:30, Bob Briscoe <ietf@bobbriscoe.net> wrote:

David,

On 19/07/2019 21:06, Black, David wrote:

Two comments as an individual, not as a WG chair:


Mostly, they're things that an end-host algorithm needs
to do in order to behave nicely, that might be good things anyways
without regard to L4S in the network (coexist w/ Reno, avoid RTT bias,
work well w/ small RTT, be robust to reordering).  I am curious which
ones you think are too rigid ... maybe they can be loosened?

[1] I have profoundly objected to L4S's RACK-like requirement (use time to detect loss, and in particular do not use 3DupACK) in public on multiple occasions, because in reliable transport space, that forces use of TCP Prague, a protocol with which we have little to no deployment or operational experience.  Moreover, that requirement raises the bar for other protocols in a fashion that impacts endpoint firmware, and possibly hardware in some important (IMHO) environments where investing in those changes delivers little to no benefit.  The environments that I have in mind include a lot of data centers.  Process wise, I'm ok with addressing this objection via some sort of "controlled environment" escape clause text that makes this RACK-like requirement inapplicable in a "controlled environment" that does not need that behavior (e.g., where 3DupACK does not cause problems and is not expected to cause problems).

For clarity, I understand the multi-lane link design rationale behind the RACK-like requirement and would agree with that requirement in a perfect world ... BUT ... this world is not perfect ... e.g., 3DupACK will not vanish from "running code" anytime soon.

As you know, we have been at pains to address every concern about L4S that has come up over the years, and I thought we had addressed this one to your satisfaction.

The reliable transports you are are concerned about require ordered delivery by the underlying fabric, so they can only ever exist in a controlled environment. In such a controlled environment, your ECT1+DSCP idea (below) could be used to isolate the L4S experiment from these transports and their firmware/hardware constraints.

On the public Internet, the DSCP commonly gets wiped at the first hop. So requiring a DSCP as well as ECT1 to separate off L4S would serve no useful purpose: it would still lead to ECT1 packets without the DSCP sent from a scalable congestion controls (which is behind Jonathan's concern in response to you).

	And this is why IPv4's protocol fiel/ IPv6's next header field are the classifier you actually need... You are changing a significant portion of TCP's observable behavior, so it can be argued that TCP-Prague is TCP by name only; this "classifier" still lives in the IP header, so no deeper layer's need to be accessed, this is non-leaky in that the classifier is unambiguously present independent of the value of the ECN bits; and it is also compatible with an SCE style ECN signaling. Since I believe the most/only likely roll-out of L4S is going to be at the ISPs access nodes (BRAS/BNG/CMTS/whatever)  middleboxes shpould not be an unsurmountable problem, as ISPs controll their own middleboxes and often even the CPEs, so protocoll ossification is not going to be a showstopper for this part of the roll-out.

Best Regards
	Sebastian
I think you've understood this from reading abbreviated description of the requirement on the list, rather than the spec. The spec. solely says:
	A scalable congestion control MUST detect loss by counting in time-based units
That's all. No more, no less.

People call this the "RACK requirement", purely because the idea came from RACK. There is no requirement to do RACK, and the requirement applies to all transports, not just TCP.

It then means that a packet with ECT1 in the IP field can be forwarded without resequencing (no requirement - it just it /can/ be). This is a network layer 'unordered delivery' property, so it's appropriate to flag at the IP layer.




Bob



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