Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft

["Rodney W. Grimes" <[e-mail]>]

> Jonathan Morton <[e-mail]> wrote:
> >> On 7 Aug, 2019, at 10:47 am, <[e-mail]> <[e-mail]> wrote:
> >> 
> >> I think to recall that a colleague noticed random initial packet drop
> >> bursts with IPERF3 too (and stopped using it).
> > 
> > These are almost certainly associated with slow-start, whose
> > exponential growth is that much harder to control than subsequent
> > linear growth.
> 
>    It's kind of silly that each new TCP connection starts with the
> assumption that it knows absolutely nothing about the likely capacity
> and congestion of the route to its destination.
> 
>    Can't we do something to fix this?

Some end systems do infact do something about this, they
cache information about there last connection on that route,
other ends systems have more complicated stuff.

I am not positive as to the current state of which data is
still maintained by a BSD kernel, but a "route" has storage for:
route -n get 192.168.114.114    
   route to: 192.168.114.114
destination: 192.168.114.114
  interface: lnc1
      flags: <UP,HOST,DONE,LLINFO,WASCLONED>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500       954 

7 things, plus an expire timer.

There is nothing in the protocols that specify this, and imho there
should never be anything in the protocols that specify the use or
non use of this type of solution.

I believe there is at least one vendor that sends the last known
download bandwidth on the connection request to there servers in
a higher layer protocol and use that information to pace the
initial packets on a new connection until new data can be
obtained.

> --
> John Leslie <[e-mail]>
-- 
Rod Grimes                                                 [e-mail]