Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Congestion Signaling (CSIG)

Christian Huitema <huitema@huitema.net> Tue, 20 February 2024 20:09 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AECC180B76 for <ippm@ietfa.amsl.com>; Tue, 20 Feb 2024 12:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2V7pyztTJuV for <ippm@ietfa.amsl.com>; Tue, 20 Feb 2024 12:09:06 -0800 (PST)
Received: from out15-27.antispamcloud.com (out15-27.antispamcloud.com [185.201.19.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2750CC14F6B8 for <ippm@ietf.org>; Tue, 20 Feb 2024 12:08:18 -0800 (PST)
Received: from xse495.mail2web.com ([66.113.197.241] helo=xse.mail2web.com) by mx196.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1rcWPX-003iyR-Ua for ippm@ietf.org; Tue, 20 Feb 2024 21:08:17 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4TfVp35Nw5z9TK for <ippm@ietf.org>; Tue, 20 Feb 2024 12:08:11 -0800 (PST)
Received: from [10.5.2.14] (helo=xmail04.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 1rcWPT-0001VT-K2 for ippm@ietf.org; Tue, 20 Feb 2024 12:08:11 -0800
Received: (qmail 24441 invoked from network); 20 Feb 2024 20:08:11 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.201.10]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <moeller0=40gmx.de@dmarc.ietf.org>; 20 Feb 2024 20:08:11 -0000
Message-ID: <9a0b8228-ed26-431c-92df-03a29d5f1a0d@huitema.net>
Date: Tue, 20 Feb 2024 12:08:10 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Sebastian Moeller <moeller0=40gmx.de@dmarc.ietf.org>, Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
Cc: tsvwg <tsvwg@ietf.org>, Jai Kumar <jai.kumar@broadcom.com>, IETF IPPM WG <ippm@ietf.org>, Nandita Dukkipati <nanditad@google.com>, iccrg@irtf.org, Naoshad Mehta <naoshad@google.com>, ccwg@ietf.org, Abhiram Ravi <abhiramr@google.com>
References: <CAF0+TDD+44TAHf7y05GzmCgbau66ey7AU2RaVroim_Tukf=7nQ@mail.gmail.com> <CALx6S35V8xyDBkN0m8kDEcNk0N734Fqq0Ne8ZJ284ZnSSUwV9w@mail.gmail.com> <CALx6S35XNyBe5=gh7JpaCKEkiXaEwPGHrDZe=E-EPkiF5mUCLA@mail.gmail.com> <CAB_+Fg5McYXt=M5MNkuxHrKrXQgZMS6PLRoVeUKiSUe5Qb7LjA@mail.gmail.com> <CALx6S35OHyhWjmkV2jiOqO-sB9Csugx0umB_yF_ann9rB8Tgbw@mail.gmail.com> <CAEsRLK9_bHrhyvFqCz3do=Ax3mKZor4EtqXY2chdfL7fzi1UMw@mail.gmail.com> <500388A6-50D3-4535-84CB-E6EF454960DD@gmx.de> <CALx6S37gOatLC_DZiM4M=e8qrzyE9y1D1i+UqOYXatd7Y6Nauw@mail.gmail.com> <918C1325-EC13-48CF-9B29-50EEB3A0FF1C@gmx.de> <CALx6S37zGrNMai+9khwG2_rpsiQuTd8bSiWbxZK-oiVEB0aimQ@mail.gmail.com> <A68A0319-7942-482D-A395-BB72901B2EA7@gmx.de> <CALx6S36AON6GkPLLcBVaq1uKxaRwgvc-txCkb9PCyX0DGs7ktw@mail.gmail.com> <4E3C7A28-C810-4420-A799-81ACC320A5D2@gmx.de>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; keydata= xjMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1RmvN J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsKWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAzjgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB8J+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
In-Reply-To: <4E3C7A28-C810-4420-A799-81ACC320A5D2@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: 66.113.197.241
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: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wTQJcK6O716WIVCzU1uqysKj/EwzSHE5FGYwwjsNRPCBkO YxLzQtjChRwcy+iZhRXmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcagYlnbzLIe7S77Bwkxve1ZxQ6V51u76v35b1wNe/MvdKX8bg7 8d8EvEyQEZCV9hJd2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEEIgtEXyXj6S3SDvReMcV 8TXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7iff8pZ9ure3k2YtJj4Q8Z7MmhlopTqh5tIz3fgmDa+poS6LDTwocagMzhhPLuvoSJD s9JZobFnc66pcCbaaJeHC8CKASqFe0kBQ5ZmwPhPJiyZvdx3ZJDsPzrvEdt+b8mxX4OQOI/UQ6jn FfMBgzwOSHunMg5j/UO+IMRndiIcrqRTLFhWSa+FhDJE4smtNqHZcpPgEJKLbDyaC/LdLvvYvNTL lHN3T+sl8MVBP7Q8cvpVB9v9zY0h8asEYmbGGsJD9ySC20IzFkBtfP+lFUR47u6Bd0UIBOkG1N4t Ojwpq713qFZSq8Fx+9otn0aqja8VKPqpdskk5LxBR/9t1zMMkdu6/R2FM84kxYRFSvC1IDg1BRW7 hzp8w3iHcOwbVtsmWfnQGGis4EvbR3jXsI0ESXwhBU2hwt/J18C+HygJl/jEzm1SsR8v3aJbN/NZ fa8pHhHaz+HPa0HAgEx4sWDF
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/cMuXwjOpNzYWUUCImactj8ONYNE>
X-Mailman-Approved-At: Wed, 21 Feb 2024 03:45:32 -0800
Subject: Re: [ippm] [tsvwg] [iccrg] New Internet Draft: Congestion Signaling (CSIG)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2024 20:09:07 -0000


On 2/20/2024 9:55 AM, Sebastian Moeller wrote:
>> That's more of a statement of security and not feasibility. There's simply no security in the Internet, so we cannot trust or validate that anonymous intermediate nodes are going to write correct information. Any plain text in a packet on the Internet is subject to inspection and modification if the data isn't authenticated, and in the worst case this could be a DoS vector by writing bad information.
> [SM3] Indeed, but e.g. for TCP you would need to know a lot about the most recent packet to be able to play games, no? So either you are on path and already can drop/duplicate packets at will or you are off path but still need a recent enough veridical packet to be able cause mischief, no? (I might be insufficiently creative in attack vectors)

I am analysis congestion control information using the framework of 
"honest signals". In human communication, "honest signals" are those 
that cannot be easily faked by the communicator. For example, smiling is 
not really a honest signal, because it is easy to fake; blushing, on the 
other hand, is hard to fake.

When it come to Internet wide congestion control, we have pretty much 
the same issue. Networks may want to fool the application for a variety 
of reasons, and may start faking congestion signals. Some of these 
signals are hard to fake. End to end data rate for example: slowing a 
specific stream of packets is hard to fake; measuring the end to end 
data rate is a pretty good indication of the state of the network. End 
to end RTT is also a rather honest signal: yes, routers could put some 
specific packets in a slow queue, but that requires resource.

Packet losses almost belong in that category. They are not hard to fake, 
routers could play favorites and selectively drop packets with a certain 
profile. But dropping too many packets affects the "quality rating" of a 
provider, so there is some pressure to not fake it. That pressure is 
probably one of the reasons behind bufferbloat. The main problem with 
packet loss as a signal is that losses may have other causes than 
congestion.

ECN is not really a honest signal. Setting a bit in a packet header does 
not require a lot of efforts, so routers could do that to play 
favorites. In fact, past bugs in some networks caused almost all packets 
to be marked as CE. Using ECN is very nice when you can trust it, but 
end nodes should probably do that cautiously, detecting for example a 
sudden raise in ECN marks rather than reacting to an average value.

ECN is just one bit. There is always a temptation to do a better ECN 
with many more bits. For example, CE directs a sender to slow down. It 
would be nice to have a corresponding "All clear" signal telling the 
senders that they can speed up. L4S attempts to do that by modulating 
the CE bit, so that a low frequency kinda indicates "all clear", while a 
high frequency says "slow down", and give some indication of how much. 
Suddenly, one bit becomes several bits, just spread over many packets.

The idea of adding more bits in packet headers is not exactly new -- see 
for example TCP QUIC Start by Sally Floyd et al., RFC 4782, January 
2007. The problem is that the more bits you add, the more you exacerbate 
issues of trust, and also risks of bugs. "Many more bits" may work in a 
controlled environment, but I really do not see that working on the 
whole Internet.

-- Christian Huitema