From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 68A283BA8E for ; Tue, 3 Apr 2018 07:54:46 -0400 (EDT) Received: by mail-oi0-x22f.google.com with SMTP id z8-v6so15686411oix.2 for ; Tue, 03 Apr 2018 04:54:46 -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=xHp4aUKldRiTcCmV3gNCbNknZu97VHO66bjRrncGDHg=; b=oWVCCzK92brTifA58zeaPaydvrn/BP11+08EOnxDR28F8x40BJ0WM82q56fKaGXwyB i+uS9E9b88xHAmjxf5eUr8bs9yIuYrUrqe/Hwgzb4iicFOwNrV417m+R2JQk90VDoNEg XRgjBk3dkSh4lZ68a7fSmkHptNbbT2U0pUmc4jr2cTkrveGJpB7FDq5Vrroixz04porK hCISjV4KBxyGzUSTar74R89M83SzNVOW0n93xLTlCqEx17zXskg37bgqUisyipvBmUVD YMGyOFM6+IU+4Zw0iHI/d75bmKxVAT4iIbcvar6y5rSq2ORFo9NT7xkV0857sdPZI1ad XdpA== 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=xHp4aUKldRiTcCmV3gNCbNknZu97VHO66bjRrncGDHg=; b=P71mZMiT336nmsSA8EDUtnouaWXn5mXdVrK3tiNX0t4JoF3oT9O7hpKoS7kuVXsbW8 e3MBms4X1V5cri5ZkXnQDGh3xdTTpvjXbhhy8R/NS/BQjdpwbwaCE4G7HO/pzA2rnGVT xd7hbsYwe6qyrvUfDd7yRg1Qiqbn68vjy99RczpyHswLeHS9xLQd9kJgg/+634HdO2WH Fe4cZqRWTTsek462O81XGF0FmQYEdYCs1Zd8azUJT+PnCmlNWR9ZUdx2GKkZvC54+cj9 b9LNqnYwCQ3L7mbM3rDM3e5F2bo+3pSQy03pRfjOpGNG6X6RvU0VQguoUDTl5s4FwJpH kOCA== X-Gm-Message-State: ALQs6tAojk2JeS1Fwz2ELjn37PfZbdcu2TJotKuzPHTrj7mHzU3etqeP 4NdfYf8Yo0NKh2MQTczZNYgCJ75goBHJsvx9gA== X-Google-Smtp-Source: AIpwx48ZbmYnQbF7KF5X9YKkFln1M7pWPizmoIt0EEY/AHaNSndscaaNqZAQKTe7DePV+lcdRHWSZdglLZAxmBshjxY= X-Received: by 2002:aca:b443:: with SMTP id d64-v6mr7530838oif.104.1522756485792; Tue, 03 Apr 2018 04:54:45 -0700 (PDT) MIME-Version: 1.0 References: <50e57074-4ca5-59f7-f010-d9b2b845a8a7@rogers.com> In-Reply-To: <50e57074-4ca5-59f7-f010-d9b2b845a8a7@rogers.com> From: Jesper Louis Andersen Date: Tue, 03 Apr 2018 11:54:34 +0000 Message-ID: To: davecb@spamcop.net Cc: bloat Content-Type: multipart/alternative; boundary="0000000000006a4b010568f05f0a" 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 11:54:46 -0000 --0000000000006a4b010568f05f0a Content-Type: text/plain; charset="UTF-8" On Mon, Apr 2, 2018 at 2:47 PM David Collier-Brown wrote: > This is not an initiative I know about, but it mentions Reno and it's > inability to use SACK, so it sounds at first hearing to be another dumb > gamer thing. Opinions, anyone? > Pure guess: They are not trying to solve the problem of bufferbloat. Rather, they are trying to solve the problem you have with any gaming platform out there, which is that most games have the characteristics they target: * Small messages rather than a stream of bytes * Usually low bandwidth * Retransmits are sometimes desired, but some times they are not (or rather: some messages quickly loose their value if they arrive too late much like in, say, VoIP). * Cryptography is a required tool since cheaters often alter messages in flight through packet rewriting. I don't necessarily think bufferbloat is on their radar in the first place here. Apart from that, it seems like a lot of things are being done correctly. I *much* prefer a message-based protocol where packets use protobufs in many scenarios over a stream-oriented protocol. The former forces people to program around having limited buffers and this usually puts a flow control scheme into their programs, whereas a badly written stream transmission just creates trouble; some of those being in the security area. Furthermore, the common case I've seen so many times are newcomers to network programming who treat TCP as being message oriented. This works nicely on a Linux localhost with a 64 kilobyte MTU, and it will pass every test in their test harness. But as soon as they move into the real world, their assumption is broken by real networks. The Valve effort completely circumvents this problem as well. As for cryptography: I'd much prefer a solution where the transport encrypts rather than needing the application to do so. IPSec I largely see as being killed by lobbying efforts from businesses who would go bankrupt if the problem was solved correctly once and for all. Though I lament that we have no AH/ESP split in the modern solutions. They just encrypt everything blindly, but the idea of being able to provide integrity through AH would have been nice in a lot of cases. (Disclaimer: I'm an Erlang programmer, so I have my opinions and ideologies about messaging-oriented platforms :) --0000000000006a4b010568f05f0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 2, 2018 at 2:47 PM David Collier-Brown <davec-b@rogers.com> wrote:
=20 =20 =20

This is=C2=A0 not an initiative I know about, but it mentions Reno a= nd it's inability to use SACK, so it sounds at first hearing to be another dumb gamer thing. Opinions, anyone?

=C2=A0Pure guess:

They are not trying to = solve the problem of bufferbloat. Rather, they are trying to solve the prob= lem you have with any gaming platform out there, which is that most games h= ave the characteristics they target:

* Small messages rat= her than a stream of bytes
* Usually low bandwidth
<= div>* Retransmits are sometimes desired, but some times they are not (or ra= ther: some messages quickly loose their value if they arrive too late much = like in, say, VoIP).
* Cryptography is a required tool since = cheaters often alter messages in flight through packet rewriting.

I don't necessarily think bufferbloat is on their radar in the= first place here.

Apart from that, it seems like a lot o= f things are being done correctly. I *much* prefer a message-based protocol= where packets use protobufs in many scenarios over a stream-oriented proto= col. The former forces people to program around having limited buffers and = this usually puts a flow control scheme into their programs, whereas a badl= y written stream transmission just creates trouble; some of those being in = the security area.

Furthermore, the common case I've = seen so many times are newcomers to network programming who treat TCP as be= ing message oriented. This works nicely on a Linux localhost with a 64 kilo= byte MTU, and it will pass every test in their test harness. But as soon as= they move into the real world, their assumption is broken by real networks= . The Valve effort completely circumvents this problem as well.

As for cryptography: I'd much prefer a solution where the transp= ort encrypts rather than needing the application to do so. IPSec I largely = see as being killed by lobbying efforts from businesses who would go bankru= pt if the problem was solved correctly once and for all. Though I lament th= at we have no AH/ESP split in the modern solutions. They just encrypt every= thing blindly, but the idea of being able to provide integrity through AH w= ould have been nice in a lot of cases.

(Disclaimer: I'= ;m an Erlang programmer, so I have my opinions and ideologies about messagi= ng-oriented platforms :)

--0000000000006a4b010568f05f0a--