Re: [tsvwg] [Ecn-sane] per-flow scheduling

"David P. Reed" <dpreed@deepplum.com> Mon, 24 June 2019 19:50 UTC

Return-Path: <dpreed@deepplum.com>
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 85F17120154 for <tsvwg@ietfa.amsl.com>; Mon, 24 Jun 2019 12:50:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=g001.emailsrvr.com
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 XJl4jmjGb_x1 for <tsvwg@ietfa.amsl.com>; Mon, 24 Jun 2019 12:50:47 -0700 (PDT)
Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087D5120058 for <tsvwg@ietf.org>; Mon, 24 Jun 2019 12:50:46 -0700 (PDT)
Received: from smtp17.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BBCD9255BE; Mon, 24 Jun 2019 15:50:45 -0400 (EDT)
X-SMTPDoctor-Processed: csmtpprox beta
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1561405845; bh=hJynLrERUKg42S8MJj14F05lm/C9Q8XK+KZMM3rtqEA=; h=Date:Subject:From:To:From; b=y3mlekRZAmdIzaUB2BPYf3EHx1iPW6zGo/i8mxewM1mo2xVJ4M/jjJ1DErVXiVvjm zeoL2h6PjQSj+kBq5LUtc5Mp549l1zvcsDKoMIW0/SAMTAG4m6mA2f89dOSk4scW0V Jw1djeRWsi4+rfHOBXUcSVfY+Fr7L7DFxkS+E99M=
Received: from app27.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8B094255C1; Mon, 24 Jun 2019 15:50:45 -0400 (EDT)
X-Sender-Id: dpreed@deepplum.com
Received: from app27.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 24 Jun 2019 15:50:45 -0400
Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app27.wa-webapps.iad3a (Postfix) with ESMTP id 721E520046; Mon, 24 Jun 2019 15:50:45 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 24 Jun 2019 15:50:45 -0400 (EDT)
X-Auth-ID: dpreed@deepplum.com
Date: Mon, 24 Jun 2019 15:50:45 -0400
From: "David P. Reed" <dpreed@deepplum.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "ecn-sane@lists.bufferbloat.net" <ecn-sane@lists.bufferbloat.net>, tsvwg IETF list <tsvwg@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_20190624155045000000_47044"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
In-Reply-To: <7F847464-70DD-4F9F-8CA5-DD3C8B65689C@gmail.com>
References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <46D1ABD8-715D-44D2-B7A0-12FE2A9263FE@gmx.de> <CAHx=1M4+sJBEe-wqCyuVyy=oDz7A+SG_ZxBbu_ZZDZiCHrX2uw@mail.gmail.com> <835b1fb3-e8d5-c58c-e2f8-03d2b886af38@gmail.com> <1561233009.95886420@apps.rackspace.com> <71EF351D-AFBF-4C92-B6B9-7FD695B68815@gmail.com> <1561241377.4026977@apps.rackspace.com> <081BAF4F-2E1C-441B-A31A-9AC70E3EDA32@gmail.com> <1561402678.523819778@apps.rackspace.com> <7F847464-70DD-4F9F-8CA5-DD3C8B65689C@gmail.com>
Message-ID: <1561405845.46329325@apps.rackspace.com>
X-Mailer: webmail/16.4.5-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/MJUB0fn3hSCZEBkLYm2Goe5yBRY>
X-Mailman-Approved-At: Tue, 25 Jun 2019 04:16:19 -0700
Subject: Re: [tsvwg] [Ecn-sane] per-flow scheduling
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: Mon, 24 Jun 2019 19:50:50 -0000

Please!
On Monday, June 24, 2019 3:31pm, "Jonathan Morton" <chromatix99@gmail.com> said:



> > On 24 Jun, 2019, at 9:57 pm, David P. Reed <dpreed@deepplum.com>
> wrote:
> >
> > TCP doesn't have a "natural sawtooth" - that is the response of TCP to a
> particular "queueing discipline" in a particular kind of a router - it would
> respond differently (and does!) if the router were to drop packets randomly on a
> Poisson basis, for example. No sawtooth at all.
> 
> I challenge you to show me a Reno or CUBIC based connection's cwnd evolution that
> *doesn't* resemble a sawtooth, regardless of the congestion signalling employed. 
> And I will show you that it either has severe underutilisation of the link, or is
> using SCE signals. The sawtooth is characteristic of the AIMD congestion control
> algorithm.
 
Of course AIMD responds with a sawtooth to a router dropping occasional packets as congestion signalling. Are you trying to pretend I'm an idiot? And various kinds of SACK cause non-sawtooth responses.
 
My overall point here is that you seem to live in a world of academic-like purity - all TCP connections are essentially huge file transfers, where there are no delays on production or consumption of packets at the endpoint, there is no multiplexing or scheduling of processes in the endpoint operating systems, etc.
 
TCP sources don't work like that in practice.

> 
> - Jonathan Morton