Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348

[Jesper Louis Andersen <jesper.louis.andersen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]

On Mon, Apr 2, 2018 at 2:47 PM David Collier-Brown <davec-b@rogers.com>
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 :)

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]