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

[Jim Gettys]

On Tue, Apr 3, 2018 at 10:48 AM, Jesper Louis Andersen <
jesper.louis.andersen at gmail.com> wrote:

> On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <michawe at ifi.uio.no> wrote:
>
>> please, please, people, take a look at the ietf taps (“transport
>> services”) 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.
>

​Middle boxes are a huge problem.
​

>
> 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.
> ​​
>
>
​To some extent: but BBR is in fact a breakthrough independent of
bufferbloat (and in fact will induce > 1RTT of buffer, which is far from
ideal).

For example, BBR works tremendously better t​han loss based congestion
avoidance algorithms in the face of high RTT/lossy networks, like those
faced in satellites or the developing world.

>
​To get to really good RTT's (with low jitter), you still need ​fq_codel
(or similar).  You just can't get there by hacking TCP no matter how hard
you try...

See both on their independent merits: it is part of the Elephant; it's easy
to think your "solution" solves
the whole problem, when it doesn't.  I will cheer both fq_codel and similar
flow queuing AQM's that may appear
*and* BBR loudly.
                                                                 - Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20180403/9f61f1be/attachment-0002.html>