From nobody Sun Nov 1 15:56:12 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 1CFEF3A0ADD for ; Sun, 1 Nov 2020 15:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no 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 AxNbgznyXFlr for ; Sun, 1 Nov 2020 15:56:02 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 0459E3A0AD6 for ; Sun, 1 Nov 2020 15:56:01 -0800 (PST) Received: from xse48.mail2web.com ([66.113.196.48] helo=xse.mail2web.com) by mx36.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kZNCU-0001oF-5Z for tcpPrague@ietf.org; Mon, 02 Nov 2020 00:55:59 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4CPXxL4nHZzLjZ for ; Sun, 1 Nov 2020 15:55:50 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kZNCQ-0004sL-IJ for tcpPrague@ietf.org; Sun, 01 Nov 2020 15:55:50 -0800 Received: (qmail 14517 invoked from network); 1 Nov 2020 23:55:50 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.139]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Nov 2020 23:55:50 -0000 To: "De Schepper, Koen (Nokia - BE/Antwerp)" , Jonathan Morton Cc: iccrg IRTF list , Bob Briscoe , tsvwg IETF list , TCP Prague List References: <1b71a610-75ea-e1d4-e3ce-f0ae6a4c12f7@bobbriscoe.net> <28247e5f-5df3-1f75-50e6-b4a7e80d5ab0@huitema.net> <61B6E9DC-8786-4CC0-9AC0-7F74E3529A73@gmail.com> <40751956-daa0-5693-d880-c45e8ca262cc@huitema.net> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <5ba51c98-9600-a55f-5d9f-bff012eb39e4@huitema.net> Date: Sun, 1 Nov 2020 15:55:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BE98C98514FF49A3DB80CDC5" Content-Language: en-US X-Originating-IP: 66.113.196.48 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.48/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.48/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD42+pgDSJdnVPeXOEK1m6uDbl kDZNUkuHiojIVh7uAUvRxM+xBZ1w6pGno+CK6C/mUZq99/v+OWrp+SY7iSuea8EuNfnjQsRqWXYP fdewBkdPR9o014ICOs9pIWX8OtLJqUALHGqxBO534sbPOpB/O8xKTagmQ3xMyVZ07UERWzx6BTXs FxcSzhpFHKuVDd8Suy8lNDS0QWWkADhl7glCR9PbrhSmW22tW1yBxgRT8bmxZJSIFVPkVVALPRKr lHlM3kWCH4Q79vaQ+COHDJAgLHQOD0r6/AaHZiEtdTMtMlgTBUa5LSawQcdT80HH17nNg8oiq9mz mwrbQbTulSg7juWBOXp8nHKe0R+FkIqN7hkFZqA6TBkpoO/ktnXt0JlLIRFsicyJMEhQFtD8PLoi nuxTyssp4L0plUGigax8zy4LpVxP5YFZg5fgueXLf6LKHDJ71JSXKkUqfqsTqwEEUOidX4Ts4xdG +C13IyWeZaLC2lfTiRPZMteoXs+GRoRWGBfTiFUgMuua665ZNZolbYOTnT6wN9gOMciuJ4QlThoh 1KxQEOw1WgWLtkQSpIiO5CAOwzF4KlWKogaY4h5dvpXked+P+aSZU/EB7YnRWs2LBDMrD7q/cJog wbqzsuokd3KVbf1SW+BycALUr5UaiYaPmF/7MAKyW1Kb4FKGpjRUxjUEXi0B+fEhaFh69PSnZtIW M4JzTFxRH3Dz7iuUi5v6swd5IHP4xIKORT1wivuloQCszo/2qS3jMvYFyyWx9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection 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: Sun, 01 Nov 2020 23:56:06 -0000 This is a multi-part message in MIME format. --------------BE98C98514FF49A3DB80CDC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/1/2020 1:53 PM, De Schepper, Koen (Nokia - BE/Antwerp) wrote: > > >>By the way, I do think that L4S makes too many hypotheses about the > CC. I wish the AQM was based on intrinsic properties, such as "this > flow is using more than its fair share of bandwidth" > > This last quote is exactly what the L4S marking is intended to do: the > smoothed marking probability over a longer time interval (about 10 > RTTs) indicates the fair target rate. Assuming we agree on 15ms being > the reference RTT, then the average rate can be r=3D2/(p*0.015)=3D133/p= > packets per second. So you can evaluate yourself if you use more or > less than the fair share. How you respond to this knowledge is up to > your CC. > I think that part of the complexity in L4S AQM comes from trying to achieve fair sharing of resource without actually implementing fair queuing. You end up expecting that implementations apply a formula and derive their packet sending rate from a smoothed average of the packet marking rate. It may work well in controlled environments, but I am afraid that very few implementations are ever going to do that in practic= e. Congestion Control algorithms are much more likely to treat packet losses, markings, or delay increases as signals that they are sending too fast, while considering their absence or lower frequency as signal that they might be able to send faster. Implementations also are likely to take into account the recent history, for example monitoring the min RTT (LEDBAT, BBR), or monitoring the recent available bandwidth (BBR). They also typically filter signals, e.g., consider only one packet loss or ECN mark per RTT (New Reno, Cubic, etc.). This is expected, because we do see packet losses arriving in batches, and can reasonably expect ECN marks to have the same behavior. But implementations are inherently selfish, do not really trust the signals from the network, and are very unlikely to end up applying the formula that you suggest. In any case, you have a scaling issue. Let's consider a 1.5Gbps link, with 15 ms delay and 1500 bytes packets. The nominal sending rate is 125,000 packets per second. The marking rate with your formula shall be p =3D 2/(r*0.015), which is about 0.0008%. Over the last 10 RTT, the connection will on average see 0.14 marks -- that is, no mark over the last 10 RTT 86% of the time. This falls well short of the requirement to provide frequent feedback! If you give up the formula, you could end up with a significantly simpler event based congestion control, in which applications slow down if they see too many CE marks, accelerate if they only see a very low marking rate, and stay put if they see an infrequent marking rate. I can see applications doing that, resulting in a fairly stable network and low delays. Of course, you will have to do some form of fair share enforcement to catch violators, but I am sure you can come up with something. -- Christian Huitema --------------BE98C98514FF49A3DB80CDC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 11/1/2020 1:53 PM, De Schepper, Koen (Nokia - BE/Antwerp) wrote:

>>By the way, I do think that L4S makes too many hypotheses about the CC. I wish the AQM was based on intrinsic properties, such as "this flow is using more than its fair share of bandwidth"

This last quote is exactly what the L4S marking is intended to do: the smoothed marking probability over a longer time interval (about 10 RTTs) indicates the fair target rate. Assuming we agree on 15ms being the reference RTT, then the average rate can be r=2/(p*0.015)=133/p packets per second. So you can evaluate yourself if you use more or less than the fair share. How you respond to this knowledge is up to your CC.

I think that part of the complexity in L4S AQM comes from trying to achieve fair sharing of resource without actually implementing fair queuing. You end up expecting that implementations apply a formula and derive their packet sending rate from a smoothed average of the packet marking rate. It may work well in controlled environments, but I am afraid that very few implementations are ever going to do that in practice.

Congestion Control algorithms are much more likely to treat packet losses, markings, or delay increases as signals that they are sending too fast, while considering their absence or lower frequency as signal that they might be able to send faster. Implementations also are likely to take into account the recent history, for example monitoring the min RTT (LEDBAT, BBR), or monitoring the recent available bandwidth (BBR). They also typically filter signals, e.g., consider only one packet loss or ECN mark per RTT (New Reno, Cubic, etc.). This is expected, because we do see packet losses arriving in batches, and can reasonably expect ECN marks to have the same behavior. But implementations are inherently selfish, do not really trust the signals from the network, and are very unlikely to end up applying the formula that you suggest.

In any case, you have a scaling issue. Let's consider a 1.5Gbps link, with 15 ms delay and 1500 bytes packets. The nominal sending rate is 125,000 packets per second. The marking rate with your formula shall be p = 2/(r*0.015), which is about 0.0008%. Over the last 10 RTT, the connection will on average see 0.14 marks -- that is, no mark over the last 10 RTT 86% of the time. This falls well short of the requirement to provide frequent feedback!

If you give up the formula, you could end up with a significantly simpler event based congestion control, in which applications slow down if they see too many CE marks, accelerate if they only see a very low marking rate, and stay put if they see an infrequent marking rate. I can see applications doing that, resulting in a fairly stable network and low delays. Of course, you will have to do some form of fair share enforcement to catch violators, but I am sure you can come up with something.

-- Christian Huitema



--------------BE98C98514FF49A3DB80CDC5--