Re: [tcpPrague] [tsvwg] ecn-l4s-id: Proposed Changed to Normative Classic ECN detection Text

Christian Huitema <huitema@huitema.net> Mon, 02 November 2020 00:11 UTC

Return-Path: <huitema@huitema.net>
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 DADDB3A0ADD for <tcpprague@ietfa.amsl.com>; Sun, 1 Nov 2020 16:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level:
X-Spam-Status: No, score=-2.134 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, URIBL_BLOCKED=0.001] 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 AJFhKzjrs8kj for <tcpprague@ietfa.amsl.com>; Sun, 1 Nov 2020 16:10:59 -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 ADE123A0ADE for <tcpPrague@ietf.org>; Sun, 1 Nov 2020 16:10:58 -0800 (PST)
Received: from xse427.mail2web.com ([66.113.197.173] helo=xse.mail2web.com) by mx165.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kZNQy-0016Pp-8r for tcpPrague@ietf.org; Mon, 02 Nov 2020 01:10:55 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CPYGf09q4zPLs for <tcpPrague@ietf.org>; Sun, 1 Nov 2020 16:10:50 -0800 (PST)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kZNQv-0000ff-T1 for tcpPrague@ietf.org; Sun, 01 Nov 2020 16:10:49 -0800
Received: (qmail 16962 invoked from network); 2 Nov 2020 00:10:49 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.139]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tcpPrague@ietf.org>; 2 Nov 2020 00:10:49 -0000
From: Christian Huitema <huitema@huitema.net>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Jonathan Morton <chromatix99@gmail.com>
Cc: iccrg IRTF list <iccrg@irtf.org>, Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, TCP Prague List <tcpPrague@ietf.org>
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> <AM0PR07MB6114083DB6F3FBA98AA2281FB9130@AM0PR07MB6114.eurprd07.prod.outlook.com> <5ba51c98-9600-a55f-5d9f-bff012eb39e4@huitema.net>
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: <fc6f56f1-add4-fdc0-4718-012ee10102bf@huitema.net>
Date: Sun, 1 Nov 2020 16:10:49 -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: <5ba51c98-9600-a55f-5d9f-bff012eb39e4@huitema.net>
Content-Type: multipart/alternative; boundary="------------72566BE0D78938900CD90A3C"
Content-Language: en-US
X-Originating-IP: 66.113.197.173
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0XvADx2zSFwG+3csxFBPBHmpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD42+pgDSJdnVPeXOEK1m6uDbl kDZNUkuHiojIVh7uAUtUS5yfxPR0LUnCfc2etzVZUZq99/v+OWrp+SY7iSuea8EuNfnjQsRqWXYP fdewBkdPR9o014ICOs9pIWX8OtLJfIWPzE7MiabwbSDoRIQJQtbNhTNyx2YOvjKTJ3Ps/x2i3GSv wir0OshyEkOwfCYvxs5/T0oXYyKdvWabEYxQFC5Ano+acIK7aoZBBKN3kq8lTiPCf+PwTb/RKAdw /TswIg1fYmNb1kgzViAoNrSrXN1jhnM/Mbva2XLV/LIEzaJm4kYWBU//ZZ8pZ1xZfmaG1NRsUdzW awx6dX0NJ8Bzt99fxN2oReTDHAyOynaY0ClENaQq/2aUAxcG3yLqjApZmdySlZou9qHIGOZDEEo7 O58ZQzrOqjAERHu4pt/Ia6wELzcGxDgkPe7eR6qspNNQGjLhGMBSrFdf8dBbPvtqJwEiRQv+PVjj wa+Z5RFCOMR3ix2Ng3ctwEt0ycHrTvD9oBpdWj8QLYr5sN4Ugz0teygCLYuflBwW1CjUUQdx8quh nJWj57cNhf7KkzliAIHWGlU4PSngKJoJ6shQV+KVUWkvZ+pWP1s35neRYWMQUWZErSs0X3oyoTc8 j/o7qulxDJ14J/ZpV+AwLTzPkgkfF2re/hsBBxzR0ZxLcHZ9dOizQO9KaEkxrOQpyJAFamkd8jAz /walAdU1F5uBDCIEXwEH5tktsnhMr4gG+2qXrJ2i00qa8JieZgni7Zekc3P+9R/2gMGq0KWAzmMf +ibVDpdplkxcBm4XM6d7s4Bx3w1WbaUe4g0kgaInvdEp64qlVpe//bVkg87Xe61e30HXuSERbInM iTBIUBbQ/Dy6Ip4D1rnEhdYtY/lMQX5s39oH5ijcGdSK77ViXbmzTYWgl82XucjoLWQ7++7jcUS/ T5w=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/HRJecdvQdiqlXxl5kfK6-Dnwx28>
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." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2020 00:11:01 -0000

On 11/1/2020 3:55 PM, Christian Huitema wrote:
>
>
> 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!
>
Sorry, bug in my spreadsheet. The marking rate is actually 0.1%, about 2
packets per RTT. Still not frequent enough for my taste, but much better
than 0.0008%. Nevertheless, the inverse relation between marking rate
and data rate is not great.

> 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
>
>
>
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague