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

From: "Scaglione, Giuseppe" <[email-masked]>
Date: Tue, 6 Aug 2019 18:39:01 +0000

Greetings,

The attached document contains data collected testing with an Ethernet switch and the new TCP-dctcp-sce and TCP-reno-sce algorithms, draft-morton-taht-tsvwg-sce-00.

Best regards,

Giuseppe Scaglione
Distinguished Technologist
R&D Lab Hardware
Aruba Networks
Hewlett Packard Enterprise
8000 Foothills Blvd.  (MS 5555)
Roseville, CA   95747
Tel : 1-916-471-9189

---

From: <[email-masked]>
Date: Wed, 7 Aug 2019 07:47:16 +0000

Hi Giuseppe,

thanks, for me a first and so far good impression. Settings seem to make sense from the point of view of someone loosely following discussion.

You correctly state that future testing closer to standard network conditions would be interesting (bigger RTT, smaller bottleneck bandwidth). Overall buffer depth information would be interesting too. "Standard test conditions" to compare the performance of different ECN marking related approaches might make sense.

I think to recall that a colleague noticed random initial packet drop bursts with IPERF3 too (and stopped using it).

Regards,

Ruediger

Von: tsvwg <[email-masked]> Im Auftrag von Scaglione, Giuseppe
Gesendet: Dienstag, 6. August 2019 20:39
An: [email-masked]
Betreff: [tsvwg] Switch testing at 25G with ECN --SCE Draft

Greetings,

Best regards,

Giuseppe Scaglione

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 8 Aug 2019 01:38:56 +0300

> On 7 Aug, 2019, at 10:47 am, <[email-masked]> <[email-masked]> wrote:
> 

These are almost certainly associated with slow-start, whose exponential growth is that much harder to control than subsequent linear growth.  It's not a fault in iperf, but a real phenomenon of TCP congestion control.

 - Jonathan Morton

---

From: John Leslie <[email-masked]>
Date: Fri, 9 Aug 2019 19:32:58 -0400

Jonathan Morton <[email-masked]> 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?

--
John Leslie <[email-masked]>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Fri, 9 Aug 2019 16:44:41 -0700 (PDT)

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

-- 
Rod Grimes                                                 [email-masked]