From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp68.iad3a.emailsrvr.com (smtp68.iad3a.emailsrvr.com [173.203.187.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EBA1C3B29E for ; Mon, 24 Jun 2019 15:50:45 -0400 (EDT) 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 (EDT) From: "David P. Reed" To: "Jonathan Morton" Cc: "Brian E Carpenter" , "ecn-sane@lists.bufferbloat.net" , "tsvwg IETF list" 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> <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 Subject: Re: [Ecn-sane] [tsvwg] per-flow scheduling X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 19:50:46 -0000 ------=_20190624155045000000_47044 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0APlease!=0AOn Monday, June 24, 2019 3:31pm, "Jonathan Morton" said:=0A=0A=0A=0A> > On 24 Jun, 2019, at 9:57 pm, David P. Ree= d =0A> wrote:=0A> >=0A> > TCP doesn't have a "natural = sawtooth" - that is the response of TCP to a=0A> particular "queueing disci= pline" in a particular kind of a router - it would=0A> respond differently = (and does!) if the router were to drop packets randomly on a=0A> Poisson ba= sis, for example. No sawtooth at all.=0A> =0A> I challenge you to show me a= Reno or CUBIC based connection's cwnd evolution that=0A> *doesn't* resembl= e a sawtooth, regardless of the congestion signalling employed. =0A> And I = will show you that it either has severe underutilisation of the link, or is= =0A> using SCE signals. The sawtooth is characteristic of the AIMD congesti= on control=0A> algorithm.=0A =0AOf course AIMD responds with a sawtooth to = a router dropping occasional packets as congestion signalling. Are you tryi= ng to pretend I'm an idiot? And various kinds of SACK cause non-sawtooth re= sponses.=0A =0AMy overall point here is that you seem to live in a world of= academic-like purity - all TCP connections are essentially huge file trans= fers, where there are no delays on production or consumption of packets at = the endpoint, there is no multiplexing or scheduling of processes in the en= dpoint operating systems, etc.=0A =0ATCP sources don't work like that in pr= actice.=0A=0A> =0A> - Jonathan Morton ------=_20190624155045000000_47044 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please!

=0A

On Monday, June 24, 2019 3:31pm, "Jonathan Morton" <chromat= ix99@gmail.com> said:

=0A
=0A

> > On 24 Jun, 2019, at 9:57 pm, David P. Re= ed <dpreed@deepplum.com>
> wrote:
> >
> &g= t; TCP doesn't have a "natural sawtooth" - that is the response of TCP to a=
> particular "queueing discipline" in a particular kind of a route= r - it would
> respond differently (and does!) if the router were t= o drop packets randomly on a
> Poisson basis, for example. No sawto= oth at all.
>
> I challenge you to show me a Reno or CUBIC= based connection's cwnd evolution that
> *doesn't* resemble a sawt= ooth, regardless of the congestion signalling employed.
> And I wi= ll show you that it either has severe underutilisation of the link, or is> using SCE signals. The sawtooth is characteristic of the AIMD cong= estion control
> algorithm.

=0A

 

= =0A

Of course AIMD responds with a sawtooth to a router= dropping occasional packets as congestion signalling. Are you trying to pr= etend I'm an idiot? And various kinds of SACK cause non-sawtooth responses.=

=0A

 

=0A

My overall po= int 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 del= ays on production or consumption of packets at the endpoint, there is no mu= ltiplexing or scheduling of processes in the endpoint operating systems, et= c.

=0A

 

=0A

TCP sources= don't work like that in practice.

=0A


> > - Jonathan Morton

=0A
 ------=_20190624155045000000_47044--