From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 AD27D3CB39 for ; Wed, 4 Apr 2018 07:06:23 -0400 (EDT) Received: by mail-qk0-x235.google.com with SMTP id u9so8542169qkk.11 for ; Wed, 04 Apr 2018 04:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=luWZO5jC3pK+/kzrCWWiS57KjhX8WxxtMnr/zqcEuBk=; b=X+AMRRhOt3Uxd99p4oMM/GjRBtRPEjbl6P86dUHquwxQ3ops/zQiWNi9s1NzF6ysju yYn2Lif8bAkEYeSZXVnmQ9HwtYBDF0p5b5PivqOHnlVheYpGLuF1kT7UstX6Yl59d/Rb 7grdQLRYpuBz0QFEUi6s46RRHKa7+HNfdRAI5dgq6Ot6srZXjUfwGzxOVCMnj6PSmSPb 5OzZhyJX47CU/4FokTmDvpkG/rlWEYqnC1QuN2re4t/y43HdJV3kkchDthB39ana0mXF oQRuQst5uzbBfhDoCt6OS55VwXHqtpJHg1+OffXpEJRRemkwG2d9LqGMCV8XEPdNJAJd NgVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=luWZO5jC3pK+/kzrCWWiS57KjhX8WxxtMnr/zqcEuBk=; b=tUHx92VItOCOUFxqcQstlTsz8xSw3lyeD3L4rRjyywonqwD8z1esqvenTIsns27I14 yPJP14FzgkaEaDBBKUg7u+Ezyp93GqRWNiANzrGpy0goiDsRALOjbO7YsiSosDfcaKIP MW3JHfK/9C8pgzDjFBubFjqmJ9kuiYE/eq1WxhMH1im/5i0MkQpUC9naiiDBafxxOS04 pXbLJRSKEJ7r3C4rnilXMBXeJQ9qORnnzbKzRC1YqiSM/uy7TqcImLJNHGyd6M6eS4Kh 8ySUf/dKRMYaXMzE20Co+OCLO5fzyTH7rtkTe36OkEiDMDaRhkN+Xvy8Stmz6uyPjqv+ 1WEw== X-Gm-Message-State: ALQs6tCVjRxEGorTaupBbM0lfsrYx3M5BXA31gPvefBfRtxUK27AVEn1 d/HoWWRUGTc+yqdqo1aOBXAWpFzSG8z/i/6MSoI= X-Google-Smtp-Source: AIpwx4+6LW3OGMkARoaapWRY35ZfKUbJkZ/PIvPWezwRfVpOFMFDkn1ce3iZIHObmZ9dWKq8PfQ7qzN+OyMSCflhwa0= X-Received: by 10.55.160.135 with SMTP id j129mr23384774qke.126.1522839983238; Wed, 04 Apr 2018 04:06:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.209.134 with HTTP; Wed, 4 Apr 2018 04:06:22 -0700 (PDT) In-Reply-To: References: <50e57074-4ca5-59f7-f010-d9b2b845a8a7@rogers.com> <8DE589C3-9537-416D-AC7C-9250464869F9@gmail.com> <0ED5B59A-5C31-4F70-A2C9-04D9EA779A7B@ifi.uio.no> From: Luca Muscariello Date: Wed, 4 Apr 2018 13:06:22 +0200 Message-ID: To: Mikael Abrahamsson Cc: Dave Taht , Jonathan Morton , bloat Content-Type: multipart/alternative; boundary="001a114fd7c4403d5a056903d0d2" 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: Wed, 04 Apr 2018 11:06:23 -0000 --001a114fd7c4403d5a056903d0d2 Content-Type: text/plain; charset="UTF-8" I'm aware of this one. The last time I checked Linux patches seemed to be abandoned. Hit ratio could be v v low if you remove UDP encap. Look at IPSEC. On Wed, Apr 4, 2018 at 12:52 PM, Mikael Abrahamsson wrote: > On Wed, 4 Apr 2018, Luca Muscariello wrote: > > And yes, flow queueing, absolutely. Flow isolation, becomes fundamental is >> such a zoo, or jungle. >> > > There was talk in IETF about a transport protocol that was proposed to do > a lot of things TCP doesn't do, but still retain some things that has been > useful with TCP. > > I think it was this one: > > https://datatracker.ietf.org/doc/draft-ietf-nvo3-gue/ > > I'd like to see it not over UDP, but rather as a native IP protocol. The > talk was about having the network being able to look into the state machine > of the protocol (MSS size, equivalent of SYN, etc) but not into payload > (which would be end-to-end encrypted). It would also be able to do muxed > streams/message based to avoid head-of-line-blocking because of single > packet loss. > > So any of this that comes up then the whole FQ machinery might benefit > frmo being able to identify flows in any new protocol, but I imagine this > is not a hard thing to do. I still have hopes for the flow label in IPv6 to > do this job, even though it hasn't seen wide adoption so far. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --001a114fd7c4403d5a056903d0d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm aware of this one. The last time I checked Linux p= atches seemed to be abandoned.
Hit ratio could be v v low if you remove= UDP encap. Look at IPSEC.


On Wed, Apr 4, 2018 at 12:52 PM, Mikael= Abrahamsson <swmike@swm.pp.se> wrote:
On Wed, 4 Apr 2018, Luca Muscariello wrote:<= br>
And yes, flow queueing, absolutely. Flow isolation, becomes fundamental is = such a zoo, or jungle.

 There was talk in IETF about a transport protocol that was proposed to do a= lot of things TCP doesn't do, but still retain some things that has be= en useful with TCP.

I think it was this one:

https://datatracker.ietf.org/doc/draft-iet= f-nvo3-gue/

I'd like to see it not over UDP, but rather as a native IP protocol. Th= e talk was about having the network being able to look into the state machi= ne of the protocol (MSS size, equivalent of SYN, etc) but not into payload = (which would be end-to-end encrypted). It would also be able to do muxed st= reams/message based to avoid head-of-line-blocking because of single packet= loss.

So any of this that comes up then the whole FQ machinery might benefit frmo= being able to identify flows in any new protocol, but I imagine this is no= t a hard thing to do. I still have hopes for the flow label in IPv6 to do t= his job, even though it hasn't seen wide adoption so far.


--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

--001a114fd7c4403d5a056903d0d2--