Re: [tcpm] initcwnd updates?

Hello Gorry,

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

Agreed fully with this.

> 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

I do not agree that IW should *ever* be unpaced, this is likely to
lead to bad behavior as IW increases, and if I am not mistaken
there is already data that shows IW=10 and unpaced easily leads
to interesting microburst events in switches.

I am also very concerned about the number 95% being tossed around,
IW's should not cause 5% scale network events, but more like a
0.01%, yes 1 loss in 1000.  This is IW, if your losing a packet
during the IW the network is already in a bad state, do not make
it worse by increasing the amount of unacknowledged traffic
to enter flight.  Rather than state this as a percentage perhaps
state it as any loss during IW MUST be acted upon.  What that
act shall be is TBD.  (Note that 5% of 10 packets is only half
a packet, but I believe this number is being used over mutliple
IW's, so thats every other IW=10 experience loss, which would be
a poor situation.)

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

I also support the idea of careful-resume and that model to get us to
faster connection startup times.

> 
> Gorry
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org