Re: [tcpm] initcwnd updates?

[Gorry Fairhurst <[e-mail]>]

On 18/03/2024 17:04, Mark Allman wrote:
> Hi Gorry!
> Hope all is well!
>
Hi Mark!!
>> I'm not sure I believe this story that the IW is just going to
>> increase, and that we want to just automate this discovery by the
>> transport protocols. I think we'll more likely discover this
>> through measurement campaigns.
> The point is to allow TCP to do the measurement campaign.  I.e.,
> allow for some level of "badness" and let the connections the server
> normally makes be "measurements".  As long as the badness is within
> some tolerable limit then whatever IW is in use works (and maybe
> could be increased).  If not, it needs dialed back until the
> measurements show it is within the limit.
>
> I don't disagree with your notion of a measurement campaign.  I just
> think in the last 30 years we have figured things out to the point
> where we don't need people involved in the measurement campaign
> anymore, that's all.
>
> allman

It's maybe true we don't need people to measure- or maybe not - that's 
an interesting question, as is: what do we instrument the starup of TCP 
or the burst characteristics of flows at speed ?

But....

I think we might need to start by agreeing what we think IW represents. 
These days, I tend to think of IW as the burst allowance permitted to be 
sent unpaced into the network. I don't expect a burst this size to be 
dropped by the path. It's probably (??) related to the deisgn of 
buffer-handling in switches.  This might grow with time as people make 
new silicon, etc

Anyway, it also is currently the starting point for congestion control. 
Although, I'd rather favour another way to better use the actual 
capacity: instead I suggest connections ought to starting faster, as per 
draft-ietf-tsvwg-careful-resume, when they have a hint to re-use an 
acceptable starting rate. My suggetsion is that many servers have access 
to data that can inform this already.

Gorry