From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5A8993CB3F for ; Tue, 3 Apr 2018 11:04:28 -0400 (EDT) Received: by mail-qk0-x244.google.com with SMTP id c188so18943110qkg.2 for ; Tue, 03 Apr 2018 08:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AcrbxIP36d8jPluRnFaMiAQQcJzXEtV3KKrmFctow/8=; b=bCyE+5QaByH9sdwI6Gl5xNSKkpUFIv/7qDk2jDQKtnsjuFkLr1EDprnHDZ9C2Gw/xy Bc+m7OhmIWTtIMQQMzWz4vtaKYJSpw7Ti49qsojdQDjJLaDQNTqhk09qqAwg49Xp0TXT ZM06YAEFWJzpoW2sNpf0cvMiIbGub8KQe2dweSFc1pnxA619yZs3bivBQcpcg5Ypkhvi EWGWDFd3ZQRI1rm/d76Kvikc/3YuEYHTy1MlK4n6JBGraSaTF8RF3AmSJ4EFvmEnVP3v UmZ6go9p4RkL/7iI5ZcxlHWi18HtYlC4GmwKDe4dWHoPAmBjhAta72rrSSAkjHXd0xT/ PjLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AcrbxIP36d8jPluRnFaMiAQQcJzXEtV3KKrmFctow/8=; b=V86zatZ3PWyOjieWRPlU3uuHwx9isOFnrdvCK/4M7b9TwpcHszk7jotGZHBbDceF/3 d/e0+R/6EondLPzprftuMhxKq5lDC8eHgQqXC8yrktBgF4aD5NIVzEfuh30qKJOnMRCc xQAuzG98pHr85IX0Mzen5NFhqVQkrIF+CO81V5Ja4Z/ULQICADqC59gsJDDwdAZ3MOzR +Q76Ts9QY3Gs+2ylQj2ezOfQZFQnymQjwzn8prPitIkq33+wkzG3KzCScb32BBpkomWQ JgUOfXgiJn2R4SUFC2sIpzNqdyKcJDNpyK72qYfk9hFIOTx7v7YeWh6Jf1iwMk2Z68BC C2Hw== X-Gm-Message-State: ALQs6tDVnfY9ghaOgLyFcwR3RN/nG+bnSqGllh+qK6DZ0D+DNOdR+A+C otSJLC9Cl1LG8JfyHSABd52SiJYNU2l24cDyMtU= X-Google-Smtp-Source: AIpwx4/GJm/sT4iaYSbAeMMobF90MdkzhmWNX4sDHuYiPEigoXhptIjIo7VSSoF+Q3zeNooWvm8MbUIgyIruI3+EzuA= X-Received: by 10.55.49.8 with SMTP id x8mr18836212qkx.66.1522767867623; Tue, 03 Apr 2018 08:04:27 -0700 (PDT) MIME-Version: 1.0 Sender: gettysjim@gmail.com Received: by 10.12.240.203 with HTTP; Tue, 3 Apr 2018 08:04:27 -0700 (PDT) In-Reply-To: References: <50e57074-4ca5-59f7-f010-d9b2b845a8a7@rogers.com> <8DE589C3-9537-416D-AC7C-9250464869F9@gmail.com> From: Jim Gettys Date: Tue, 3 Apr 2018 11:04:27 -0400 X-Google-Sender-Auth: auidcnS7Mv7NU7UH9E2i4hUnYXw Message-ID: To: Jesper Louis Andersen Cc: Michael Welzl , Jonathan Morton , bloat Content-Type: multipart/alternative; boundary="001a11490d68d33cf10568f3055e" Subject: Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 15:04:28 -0000 --001a11490d68d33cf10568f3055e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 3, 2018 at 10:48 AM, Jesper Louis Andersen < jesper.louis.andersen@gmail.com> wrote: > On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl wrote: > >> please, please, people, take a look at the ietf taps (=E2=80=9Ctransport >> services=E2=80=9D) working group :-) >> >> > I tried looking it up. It seems the TAPS WG is about building a consisten= t > interface to different protocols in order to get a new interface rather > than, say, the bsd socket interface. > > But my search turned up several drafts from the WG. Did you have one in > particular in mind? > > I think the major reason to implement new protocols inside UDP is mainly > due to a lot of existing devices out there, namely firewalls, NAT systems= , > and so on. The internet is extending itself by successive patching of old= er > standards, rather than a replacement of older standards. I do note that > this is how biological systems tend to work as well, but I have no good > reason as to why that is what happens with internet standards where we in > principle could redesign things. But perhaps already deployed stuff makes > the systems susceptible to iterative patching. > =E2=80=8BMiddle boxes are a huge problem. =E2=80=8B > > The bufferbloat angle is also pretty clear: CoDel is a brilliant solution > but it requires you to change queues in the network. So it seems people a= re > trying to patch TCP instead, through something like BBR; again mimicking = a > biological system. > =E2=80=8B=E2=80=8B > > =E2=80=8BTo some extent: but BBR is in fact a breakthrough independent of bufferbloat (and in fact will induce > 1RTT of buffer, which is far from ideal). For example, BBR works tremendously better t=E2=80=8Bhan loss based congest= ion avoidance algorithms in the face of high RTT/lossy networks, like those faced in satellites or the developing world. > =E2=80=8BTo get to really good RTT's (with low jitter), you still need =E2= =80=8Bfq_codel (or similar). You just can't get there by hacking TCP no matter how hard you try... See both on their independent merits: it is part of the Elephant; it's easy to think your "solution" solves the whole problem, when it doesn't. I will cheer both fq_codel and similar flow queuing AQM's that may appear *and* BBR loudly. - Jim --001a11490d68d33cf10568f3055e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Ap= r 3, 2018 at 10:48 AM, Jesper Louis Andersen <jesper.louis.= andersen@gmail.com> wrote:
On Tue, Apr 3, 2018 at= 4:27 PM Michael Welzl <michawe@ifi.uio.no> wrote:
please, please, people, take a look at the ietf= taps (=E2=80=9Ctransport services=E2=80=9D) working group=C2=A0 :-)


I tried lookin= g it up. It seems the TAPS WG is about building a consistent interface to d= ifferent protocols in order to get a new interface rather than, say, the bs= d socket interface.

But my search t= urned up several drafts from the WG. Did you have one in particular in mind= ?

I think the major reason to imple= ment new protocols inside UDP is mainly due to a lot of existing devices ou= t there, namely firewalls, NAT systems, and so on. The internet is extendin= g itself by successive patching of older standards, rather than a replaceme= nt of older standards. I do note that this is how biological systems tend t= o work as well, but I have no good reason as to why that is what happens wi= th internet standards where we in principle could redesign things. But perh= aps already deployed stuff makes the systems susceptible to iterative patch= ing.

=E2=80=8BMiddle boxes are a huge problem.
=
=E2=80=8B

The bufferbloat angle is= also pretty clear: CoDel is a brilliant solution but it requires you to ch= ange queues in the network. So it seems people are trying to patch TCP inst= ead, through something like BBR; again mimicking a biological system.
=E2=80=8B= =E2=80=8B


=E2=80=8BTo some extent: but BBR is = in fact a breakthrough independent of bufferbloat (and in fact will induce = > 1RTT of buffer, which is far from ideal).

For example, BBR works tremendously better t=E2=80=8B= han loss based congestion avoidance algorithms in the face of high RTT/loss= y networks, like those
faced in satellites or the developing world.

=E2=80=8BTo get to really good RTT'= s (with low jitter), you still need =E2=80=8Bfq_codel (or similar).=C2=A0 Y= ou just can't get there by hacking TCP no matter how hard you try...

See both on their independe= nt merits: it is part of the Elephant; it's easy to think your "so= lution" solves
the whole problem, when it doesn't.=C2=A0 I will cheer both fq_cod= el and similar flow queuing AQM's that may appear
*and* BBR loudly.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Jim


--001a11490d68d33cf10568f3055e--