Re: [Congress] CONGRESS is about ready to go

[Michael Welzl <[e-mail]>]

Hi everyone,

I can’t resist chiming in  :-)    First, many thanks to you two for reading our paper!

More in line below - and cutting some stuff:

> On 28 Feb 2023, at 05:29, Christian Huitema <[e-mail]> wrote:
> 
> Matt,
> 
> It is not obvious to me that the "diminishing Feedback" problem studied by Welzl & al. is related to ACK thinning. Succinctly, they are arguing that a majority of flows are too short lived to be able to measure network bandwidth using end to end mechanism, that this leads to under-using the network capacity, that the problem is not amenable to end to end solutions, and that any solution will have to involve signalling by the network to the transport. I don't see any direct relation between that line of reasoning and a discussion of whether we should send one ACK per RTT, or 4, or one ACK for 2 packets.

I agree with that: the problem is the growing operational range in which any end-to-end cc. mechanism can’t learn anything about how loaded a path is. Sending more or less e2e ACKs is orthogonal to that.


> The discussion of ACK thinning is well advanced in the QUIC WG, see: https://www.ietf.org/archive/id/draft-ietf-quic-ack-frequency-02.html. (The authors have left the draft expire, but this is very much an active discussion.) The draft is already implemented and deployed in multiple QUIC stacks -- typically aiming for 4 ACKs per RTT, but the actual draft does not say that.

FWIW, I’m a fan of this draft. There may be various good reasons to want to control the number of ACKs. E.g., ACK cc., but more importantly perhaps: reducing the number of ACKs might have an important impact on battery life of wireless end devices.  But, I personally don’t take a stance on whether considerations on the number of ACKs to send, things like ACK thinning etc. should be in the scope of CONGRESS or not.

Instead:  ** HIJACK ALERT **:  here and below, it gets off-topic…   feel free to move this to ICCRG if this seems more appropriate.

The problem our paper identified is not only about being short-lived, but also about the fact that lower-end capacities don’t appear to “go away” as quickly as higher-end capacities are being installed… probably just a result of different upgrade speeds across the world. As a result, a uniform e2e approach will inevitably become less and less suitable. E.g., a fixed initial window X will be too small for even more paths, and too large for even more paths… it will become impossible to get this right. I write in future tense, but already now, people are using quite a range of non-standard values for the IW; what does that tell us?  That connections are *already* getting customized to the operational environment, to some degree.

Thus, I wonder - Matt:

>> (BTW, although I agree with the problem statement, I don't agree with their conclusion)
>> [1] Future Internet Congestion Control: The Diminishing Feedback Problem
>> Michael Welzl, Peyman Teymoori, Safiqul Islam, David Hutchison, Stein Gjessing
>> https://arxiv.org/abs/2206.06642 <https://arxiv.org/abs/2206.06642>

why don’t you agree with the conclusion?  (which is: at some point, CC can’t really just be e2e anymore)

Cheers,
Michael