From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 7FA4F3CB40 for ; Tue, 3 Apr 2018 10:48:33 -0400 (EDT) Received: by mail-oi0-x22b.google.com with SMTP id u84-v6so16188087oie.10 for ; Tue, 03 Apr 2018 07:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jqXZAlEKb6S/6MN0ZF1HSFvOU5jN+grsxgf7qXK/62o=; b=Nsg17gHAayRN9zndHc5sAvCJL1v90Ovuh0bE7SOU2eMgj9reHjUJcLW90MucFz0ik6 jos9XMbNZ3kjJZUEylkD1aLvvrBMU7nUM/WxNiExZo7J3qTnY/zmNfUgYsbRN5/JiIkU 5uUDVEIyID0yiArjfBfrmJ6pAXQAM4mcgZ4N3tsq442+q18lNhQY56FbFDcKz9rLfzAk popPS/fpxf0L7I0Cj/bpR3XHaqpkoEfYiJVEpRGL1E7nbrTN4tiBqqsVEpNDlvi6hGxQ 8GHxy9RkbRHyHFU6DPrkZuSW60Vl9C7iF4wb01ORsGfoinNdzzV58OVf7r4R9FEfQmu9 YXmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jqXZAlEKb6S/6MN0ZF1HSFvOU5jN+grsxgf7qXK/62o=; b=JWQL/d9UJmpdbI+5U/nSxf3AESI/uiHw9xPrE0osZmtGGR9aZg9WufLia99SQA2zyf UFc1LIucXQQ3ewB4b0ygieIKOnI+0MsvZtf3aCAFhixlzHUbdeT0dZ23nwk26IpN56Ii H6glgzQW/iZW8umOH51MOe32NeozsjBH7bgWUbdG80EXUUqUm7Nkz6l0A6cVJiyCNdol gwSuvAspBww873MbIbu+y1cYDowYxek+luqEg1MUSGMNfXi0tcdY+8EZcRtq++6CuYxK MTsUfhianmYxgdmPIp4qcOA0lWXLSBaq58MplNdauZXeqO5HaM3H8YhMX41tS0ED1Q/h MSvQ== X-Gm-Message-State: ALQs6tCyzPLl0g1ELsvKk2Yh3tCZ+DbZzyE1JahZnae80jlnYAJxvuH4 J3MBr/Zg1IlcYlswLIoVYxBLKL3Omz1zM/DtpA== X-Google-Smtp-Source: AIpwx49BpT0abc0YnYTN/Gav+d8EKeU1eAA7XH9X8nqUoeOw4z4UecfH9wv9tYYq3jI0Mi47Ene62Um7FNZKDih+2NA= X-Received: by 2002:aca:cfc4:: with SMTP id f187-v6mr7162791oig.333.1522766912856; Tue, 03 Apr 2018 07:48:32 -0700 (PDT) MIME-Version: 1.0 References: <50e57074-4ca5-59f7-f010-d9b2b845a8a7@rogers.com> <8DE589C3-9537-416D-AC7C-9250464869F9@gmail.com> In-Reply-To: From: Jesper Louis Andersen Date: Tue, 03 Apr 2018 14:48:21 +0000 Message-ID: To: Michael Welzl Cc: Mikael Abrahamsson , Jonathan Morton , bloat Content-Type: multipart/alternative; boundary="000000000000eaa9690568f2cc5f" 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 14:48:33 -0000 --000000000000eaa9690568f2cc5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 consistent 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 older 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. 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 are trying to patch TCP instead, through something like BBR; again mimicking a biological system. --000000000000eaa9690568f2cc5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 looking it up= . It seems the TAPS WG is about building a consistent interface to differen= t protocols in order to get a new interface rather than, say, the bsd socke= t interface.

But my search turned u= p several drafts from the WG. Did you have one in particular in mind?
I think the major reason to implement ne= w 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 itsel= f by successive patching of older standards, rather than a replacement of o= lder 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 inte= rnet standards where we in principle could redesign things. But perhaps alr= eady deployed stuff makes the systems susceptible to iterative patching.
The bufferbloat angle is also pretty = clear: CoDel is a brilliant solution but it requires you to change queues i= n the network. So it seems people are trying to patch TCP instead, through = something like BBR; again mimicking a biological system.
--000000000000eaa9690568f2cc5f--