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

"Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Fri, 09 August 2019 23:44 UTC

Return-Path: <freebsd@gndrsh.dnsmgr.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EE612008F for <tsvwg@ietfa.amsl.com>; Fri, 9 Aug 2019 16:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLQRWC6Ic4NV for <tsvwg@ietfa.amsl.com>; Fri, 9 Aug 2019 16:44:46 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BC6120073 for <tsvwg@ietf.org>; Fri, 9 Aug 2019 16:44:46 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x79Nig2P099810; Fri, 9 Aug 2019 16:44:42 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net)
Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x79NifkM099809; Fri, 9 Aug 2019 16:44:41 -0700 (PDT) (envelope-from freebsd)
From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>
Message-Id: <201908092344.x79NifkM099809@gndrsh.dnsmgr.net>
In-Reply-To: <20190809233258.GG51059@verdi>
To: John Leslie <john@jlc.net>
Date: Fri, 9 Aug 2019 16:44:41 -0700 (PDT)
CC: Jonathan Morton <chromatix99@gmail.com>, tsvwg@ietf.org
Reply-To: rgrimes@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/dJQCgWpKweCBMuHszR66r1wfigI>
Subject: Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2019 23:44:48 -0000

> Jonathan Morton <chromatix99@gmail.com> wrote:
> >> On 7 Aug, 2019, at 10:47 am, <Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de> 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 <john@jlc.net>
-- 
Rod Grimes                                                 rgrimes@freebsd.org