From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp92.iad3a.emailsrvr.com (smtp92.iad3a.emailsrvr.com [173.203.187.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 345863B2A4 for ; Thu, 18 Jul 2019 11:52:23 -0400 (EDT) Received: from smtp12.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F19D8250EA; Thu, 18 Jul 2019 11:52:22 -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=1563465142; bh=I/xqWMhWmZvR4fGj4VvougkdmIdLousTE979XwYGUrA=; h=Date:Subject:From:To:From; b=ja8uHqTb1C3Lzcvid7cKvBSU2rcfHBh1YLmj98Y4QCshP4vaZlF0sSLDQFOkGokNv Bsqb88F2a/dcaFRgKfQQTivRiPXjPQzYTAKOxiM5RCuG0cwBL8m/gQXDsn5x8lyqfV /yxtQ9FYHeJqWeOxD+5QN3Fxg3w2xExj0dIyTZqc= Received: from app3.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BC2B825166; Thu, 18 Jul 2019 11:52:22 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app3.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 18 Jul 2019 11:52:22 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app3.wa-webapps.iad3a (Postfix) with ESMTP id A81C3A0042; Thu, 18 Jul 2019 11:52:22 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Thu, 18 Jul 2019 11:52:22 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Thu, 18 Jul 2019 11:52:22 -0400 (EDT) From: "David P. Reed" To: "Jonathan Morton" Cc: "Sebastian Moeller" , "ecn-sane@lists.bufferbloat.net" , "Bob Briscoe" , "tsvwg IETF list" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <368B308A-C17C-42C6-AA37-F48DF6BC06AA@gmail.com> References: <350f8dd5-65d4-d2f3-4d65-784c0379f58c@bobbriscoe.net> <40605F1F-A6F5-4402-9944-238F92926EA6@gmx.de> <1563401917.00951412@apps.rackspace.com> <368B308A-C17C-42C6-AA37-F48DF6BC06AA@gmail.com> Message-ID: <1563465142.686423080@apps.rackspace.com> X-Mailer: webmail/16.4.5-RC Subject: Re: [Ecn-sane] 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: Thu, 18 Jul 2019 15:52:23 -0000 =0A=0AOn Thursday, July 18, 2019 12:31am, "Jonathan Morton" said:=0A=0A>> On 18 Jul, 2019, at 1:18 am, David P. Reed wrote:=0A>>=0A>> So what are we talking about here (ignoring t= he fine points of SCE, some of which=0A>> I think are debatable - especiall= y the focus on TCP alone, since much traffic=0A>> will likely move away fro= m TCP in the near future.=0A> =0A> As a point of order, SCE is not specific= to TCP. TCP is merely the most=0A> convenient congestion-aware protocol t= o experiment with, and therefore the one we=0A> have adapted first. Other = protocols which already are (or aspire to be) TCP=0A> friendly, especially = QUIC, should also be straightforward to adapt to SCE.=0A>=0AI agree that it= is important to show that SCE in the IP layer can be interpreted in each c= ongestion management system, and TCP is a major one. Ideally there would be= a general theory that is protocol and use case agnostic, so that the funct= ions in IP are helpful both in particular protocols and also in the very im= portant case of interacti0ns between different coexisting protocols. I beli= eve that SCE can be structured so that it serves that purpose as more and m= ore protocols that are based on UDP generate more and more traffic - =0Awhe= n we designed UDP we decided NOT to try to put congestion management in UDP= deliberately, for two reasons:=0A1) we didn't yet have a good congestion m= anagement approach for TCP, and=0A2) major use cases that argued for UDP (p= acket speech, in particular, but lots of computer-computer interactions on = LANs, such as Remote Procedure Calls, etc.) were known to require different= approaches to congestion management beyond the basic packet-drop (such as = rate management via compression variation).=0AUDP was part of the design ch= oice to allow end-to-end agreement about congestion management implementati= on.=0AWe now have a very complex protocol due to the WWW, that imperfectly = works on TCP. Thus, a new UDP based protocol framework is proposed, and wil= l be quite heavily used in access networks that need congestion management,= both at the server end and the client end.=0AAnd we have heavy use of medi= a streaming (though it matches TCP adequately well, being file-transfer-lik= e due to buffering at the receiving end). =0A=0AGoogle and others are worki= ng hard to transition entirely away from HTTP/TCP to HTTP/QUIC/UDP. This tr= ansition will be concurrent, if not prior, to SCE integration into IP. I wo= uld hope that QUIC could use SCE to great advantage, especially in helping = the co-existence of two competing uses for the same bottleneck paths withou= t queueing delay.=0A=0AThat's the case that matters to me, along with RTP a= nd other uses. From browser-level monitoring, we already see many landing w= eb pages open up HTTP requests to 100's of different server hosts concurren= tly. Yes, that is hundreds for one, count them, one click.=0A=0AThis is not= a bad thing. The designers of the Internet should not be allowed to say th= at it is wrong. Because it isn't wrong - it's exactly what the Internet is = supposed to be able to do! However, the browser or its host must have the i= nformation to avoid queue overflow in this new protocol. That means a usefu= l means like SCE=0A=0AIt also, I believe, means that arbitration based on "= flows" matter. So per-flow interactions matter. I don't know, but I believe= that when lots of browsers end up sharing a bottleneck link/queue, per-flo= w scheduling may help a reasonable amount, primarily by preventing starvati= on of resources. (In scheduling of parallel computing, we call that "preven= tion of livelock". And when you have a hundred processors on a computer - w= hich is what my day job supports, you get livelock ALL the time if you don'= t guarantee that all contenders on a resource get a chance.) What does NOT= matter is some complex (intserv/diffserv) differentiation at the router le= vel, or at least not much.=0A=0A=0A> I should also note that TCP is the de-= facto gold standard, by which all other=0A> congestion control is measured,= for better or worse. SCE is included in this,=0A> insofar as competing re= asonably with standard TCP flows under all reasonable=0A> network condition= s is necessary to introduce a new congestion control paradigm. =0A> This, I= think, is also part of the end-to-end principle.=0A> =0A> - Jonathan Mort= on=0A