<div dir="ltr">On Mon, Apr 2, 2018 at 2:47 PM David Collier-Brown <<a href="mailto:davec-b@rogers.com">davec-b@rogers.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>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?<br>
    </p>
    <div class="m_361962697792811748moz-forward-container"></div></div></blockquote><div> Pure guess:<br><br></div><div>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:<br><br></div><div>* Small messages rather than a stream of bytes<br></div><div>* Usually low bandwidth<br></div><div>* 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).<br></div><div>* Cryptography is a required tool since cheaters often alter messages in flight through packet rewriting.<br><br></div><div>I don't necessarily think bufferbloat is on their radar in the first place here.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>(Disclaimer: I'm an Erlang programmer, so I have my opinions and ideologies about messaging-oriented platforms :)<br><br></div></div></div>