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

Hi Christian,


> On 20. Feb 2024, at 21:08, Christian Huitema <[email protected]> wrote:
> 
> 
> 
> 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.

[SM] This is the approach that BBR went, and it ran smack into not working well on paths with AQM at the bottleneck. It now detects and special cases these situations, but this shows that achievable rate and delay are NOT sufficient pieces of information, at least not generally.

> 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.

[SM] But that is the point, L4S already uses a multi-bit signal, albeit one that combined the trust problem withe problem of rate codes... And that latter thing clearly isa not generally understood, I hear proposals for QUIC to onle send the fiorst CE mark quickly to the sender while delaying followingCE marks is considered OK. That is IMHO not how rate coding works, or at least not how it works well and in a timely fashion, but I digress. My point is the multibit horse is out of the barn, now we can at least do multibit correctly... (One of the other flaws of the L4S approach is that the congestin state rate code gets sprayed over a set of packets of wildy different flows).

> The idea of adding more bits in packet headers is not exactly new

[SM] Yes that has been quite obvious for a long time, but recent research has demonstrated the superiority of true multi-bit over single-bit other bit banged rate codes...

> -- 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.

[SM] congestion information might not need many more bits... see Arslan, Serhat, and Nick McKeown. “Switches Know the Exact Amount of Congestion.” In Proceedings of the 2019 Workshop on Buffer Sizing, 1–6, 2019. where a 4 bit signal already delivers most of the improvement. Now I am not saying 4bit is the perfect solution, but I am also not convinced that 'Many more bits' are required and that hence the increase in attack surface might well be worth the improvement in congestion response.

Sebastian

> 
> -- Christian Huitema
> 

_______________________________________________
ippm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ippm