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

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

[David Collier-Brown]

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

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?

--dave (I used to work for World Gaming) c-b

-------- Forwarded Message --------
Subject: 	Four short links: 2 April 2018
Date: 	Mon, 02 Apr 2018 11:40:00 GMT
From: 	Nat Torkington <>


https://www.oreilly.com/ideas/four-short-links-2-april-2018

Four short links: 2 April 2018

/Game Networking, Grep JSON, Voting Ideas, and UIs from Pictures/

 1. Valve's Networking Code
    <https://github.com/ValveSoftware/GameNetworkingSockets> -- /a basic
    transport layer for games. The features are: connection-oriented
    protocol (like TCP)...but message-oriented instead of
    stream-oriented; mix of reliable and unreliable messages; messages
    can be larger than underlying MTU, the protocol performs
    fragmentation and reassembly, and retransmission for reliable;
    bandwidth estimation based on TCP-friendly rate control (RFC 5348);
    encryption; AES per packet, Ed25519 crypto for key exchange and cert
    signatures; the details for shared key derivation and per-packet IV
    are based on Google QUIC; tools for simulating loss and detailed
    stats measurement./
 2. gron <https://github.com/tomnomnom/gron/> -- grep JSON from the
    command line.
 3. The Problem With Voting
    <https://medium.com/@nayafia/the-problem-with-voting-8cff39f771e8>
    -- I don't agree with all of the analysis, but the proposed
    techniques are interesting. I did like the term "lazy consensus"
    /where consensus is assumed to be the default state (i.e., “default
    to yes”). The underlying theory is that most proposals are not
    interesting enough to discuss. But if anyone does object, a
    consensus seeking process begins./ (via Daniel Bachhuber
    <https://danielbachhuber.com/2018/03/30/nothing-is-sacred/>)
 4. pix2code <https://arxiv.org/abs/1705.07962> -- open source
    <https://github.com/tonybeltramelli/pix2code> code that generates
    Android, iOS, and web source code for a UI from just a photo. It's
    not coming for your job any time soon (/over 77% of accuracy/), but
    it's still a nifty idea. (via Two Minute Papers <http://bit.ly/2uGxWu3>)

Continue reading Four short links: 2 April 2018. 
<https://www.oreilly.com/ideas/four-short-links-2-april-2018>


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

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

[Jesper Louis Andersen]

[-- 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 --]

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

[Jonathan Morton]

> On 3 Apr, 2018, at 2:54 pm, Jesper Louis Andersen <jesper.louis.andersen@gmail.com> wrote:
> 
> 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.

I'm reminded of the original taxonomy where "reliable stream" (TCP) and "unreliable datagram" (UDP) were only two possibilities in a much wider kingdom.  The absence of "reliable datagram" in the Internet protocol suite always struck me as odd, though "unreliable stream" seemed like a contradiction in terms once you got into packet switching networks (VoIP notwithstanding).  In the end, people have kept reinventing "reliable datagram" protocols on top of UDP, whenever they ran up against requirements that TCP didn't fulfil.

 - Jonathan Morton

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

[Mikael Abrahamsson]

On Tue, 3 Apr 2018, Jonathan Morton wrote:

> notwithstanding).  In the end, people have kept reinventing "reliable 
> datagram" protocols on top of UDP, whenever they ran up against 
> requirements that TCP didn't fulfil.

Yes, for multiple reasons. TCP is ossified and typically lives in the OS, 
because of NAT the only options for protocols that work are TCP and UDP, 
so if you want to move your "transmission stack" to userspace, your only 
choice is UDP. So enter things like QUIC and others that are mux:ed stream 
protocols over UDP, which can then live in userland on all major operating 
systems.

This is not ideal, but it's not strange that this is happening. The only 
way to innovate as an application/protocol developer is to use UDP.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[Michael Welzl]

please, please, people, take a look at the ietf taps (“transport services”) working group  :-)


Sent from my iPhone

> On 3 Apr 2018, at 14:35, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
>> On Tue, 3 Apr 2018, Jonathan Morton wrote:
>> 
>> notwithstanding).  In the end, people have kept reinventing "reliable datagram" protocols on top of UDP, whenever they ran up against requirements that TCP didn't fulfil.
> 
> Yes, for multiple reasons. TCP is ossified and typically lives in the OS, because of NAT the only options for protocols that work are TCP and UDP, so if you want to move your "transmission stack" to userspace, your only choice is UDP. So enter things like QUIC and others that are mux:ed stream protocols over UDP, which can then live in userland on all major operating systems.
> 
> This is not ideal, but it's not strange that this is happening. The only way to innovate as an application/protocol developer is to use UDP.
> 
> -- 
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

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

[Jesper Louis Andersen]

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

On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <michawe@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.

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.

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

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

[Jim Gettys]

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

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

> On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <michawe@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

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

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

[Jesper Louis Andersen]

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

On Tue, Apr 3, 2018 at 5:04 PM Jim Gettys <jg@freedesktop.org> wrote:

> ​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...
>
>
I agree with you on all points here. However, any change which patches an
existing bad system is far more likely to win in the long run, also if it
is bad in some way. Momentum is a killer of good solutions. I wish I had a
ramification for this observation, but I currently don't.

My hunch is that every new generation of young programmers wants to put
their mark on the system. As a result, they take what worked well on level
N-1 and proceed to build N on top of it. But the beanstalk never withers,
so each level is present in said stack, still, after all these years.

(Aside: The codel approach also has worked really well for me internally in
Erlang systems as a way to maintain queue load. Far better than many other
flow control schemes).

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

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

[David Collier-Brown]

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

The phenomenon is called "lava flow", and is a classic anti-pattern 
illustrated at http://antipatterns.com/lavaflow.htm
Their approach to fixing is ancient, though: there are 
correctness-preserving refactorings for some of the problem space.

Alas, I don't know if middleboxes are correctable... maybe if they are 
ones which only care about the IP layer?

--dave

On 04/04/18 08:45 AM, Jesper Louis Andersen wrote:
> On Tue, Apr 3, 2018 at 5:04 PM Jim Gettys <jg@freedesktop.org 
> <mailto:jg@freedesktop.org>> wrote:
>
>     ​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...
>
>
> I agree with you on all points here. However, any change which patches 
> an existing bad system is far more likely to win in the long run, also 
> if it is bad in some way. Momentum is a killer of good solutions. I 
> wish I had a ramification for this observation, but I currently don't.
>
> My hunch is that every new generation of young programmers wants to 
> put their mark on the system. As a result, they take what worked well 
> on level N-1 and proceed to build N on top of it. But the beanstalk 
> never withers, so each level is present in said stack, still, after 
> all these years.
>
> (Aside: The codel approach also has worked really well for me 
> internally in Erlang systems as a way to maintain queue load. Far 
> better than many other flow control schemes).
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain


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

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

[Michael Welzl]

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


> On Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen <jesper.louis.andersen@gmail.com> wrote:
> 
> On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <michawe@ifi.uio.no <mailto:michawe@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?

Thanks for taking a look!
Indeed, it’s about a consistent interface - I was provoked to send this message by the reference to ossification, and talk of messages (lacking in TCP).
Sure, when you’re in control of both ends of a connection, you can build whatever you want on top of UDP - but there’s a lot of wheel re-inventing there. Really, the transport layer can’t change as long as applications (or their libraries) are exposed to only the services of TCP and UDP, and thereby statically bound to these transport protocols.

I think I’d recommend this draft as a starting point:  https://taps-api.github.io/drafts/draft-trammell-taps-interface.html <https://taps-api.github.io/drafts/draft-trammell-taps-interface.html>

Cheers,
Michael


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

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

[Mikael Abrahamsson]

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

On Tue, 3 Apr 2018, Michael Welzl wrote:

> Sure, when you’re in control of both ends of a connection, you can build 
> whatever you want on top of UDP - but there’s a lot of wheel 
> re-inventing there. Really, the transport layer can’t change as long as 
> applications (or their libraries) are exposed to only the services of 
> TCP and UDP, and thereby statically bound to these transport protocols.

I'm aware of TAPS and I have been trying to gather support for this kind 
of effort for years now, and I'm happy to see there is movement. I have 
also heard encouraging talk from several entities interested in actually 
doing serious work in this area, including some opensourcing part of their 
now non-FOSS code-base as part of that work.

So we need applications to be able to get more access to what's going on 
the wire, including access to non-TCP/UDP, but also to be able to create 
"pluggable TCP-stacks" so that a host can have several different ones, and 
the user can install new ones even on older operating systems.

With more and more IPv6 around, I hope we'll be able to deploy new 
protocols that are not TCP/UDP (A+P), and that this will bring back some 
innovation in that area.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[Dave Taht]

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

How dead is posix these days? Ietf does not generally do apis well.

On Tue, Apr 3, 2018, 9:14 AM Michael Welzl <michawe@ifi.uio.no> wrote:

>
> On Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen <
> jesper.louis.andersen@gmail.com> wrote:
>
> On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <michawe@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?
>
>
> Thanks for taking a look!
> Indeed, it’s about a consistent interface - I was provoked to send this
> message by the reference to ossification, and talk of messages (lacking in
> TCP).
> Sure, when you’re in control of both ends of a connection, you can build
> whatever you want on top of UDP - but there’s a lot of wheel re-inventing
> there. Really, the transport layer can’t change as long as applications (or
> their libraries) are exposed to only the services of TCP and UDP, and
> thereby statically bound to these transport protocols.
>
> I think I’d recommend this draft as a starting point:
> https://taps-api.github.io/drafts/draft-trammell-taps-interface.html
>
> Cheers,
> Michael
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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

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

[Michael Welzl]

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

well - they have been refusing too long to do them at all. i guess that’s part of the problem

Sent from my iPhone

> On 4 Apr 2018, at 09:42, Dave Taht <dave.taht@gmail.com> wrote:
> 
> How dead is posix these days? Ietf does not generally do apis well.
> 
>> On Tue, Apr 3, 2018, 9:14 AM Michael Welzl <michawe@ifi.uio.no> wrote:
>> 
>>> On Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen <jesper.louis.andersen@gmail.com> wrote:
>>> 
>>>> On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <michawe@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?
>> 
>> Thanks for taking a look!
>> Indeed, it’s about a consistent interface - I was provoked to send this message by the reference to ossification, and talk of messages (lacking in TCP).
>> Sure, when you’re in control of both ends of a connection, you can build whatever you want on top of UDP - but there’s a lot of wheel re-inventing there. Really, the transport layer can’t change as long as applications (or their libraries) are exposed to only the services of TCP and UDP, and thereby statically bound to these transport protocols.
>> 
>> I think I’d recommend this draft as a starting point:  https://taps-api.github.io/drafts/draft-trammell-taps-interface.html
>> 
>> Cheers,
>> Michael
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat

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

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

[Mikael Abrahamsson]

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

On Wed, 4 Apr 2018, Michael Welzl wrote:

> well - they have been refusing too long to do them at all. i guess 
> that’s part of the problem

It's not about refusing to do so, it's because other SDOs have told the 
IETF not to. If IETF tries to touch POSIX, the SDO that does POSIX doesn't 
appreciate this.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[Mikael Abrahamsson]

On Wed, 4 Apr 2018, Dave Taht wrote:

> How dead is posix these days? Ietf does not generally do apis well.

POSIX nowadays is

http://pubs.opengroup.org/onlinepubs/9699919799/

My take on it is that the IETF should not be scared to do APIs, even 
though there is a lot of resistance still.

However, the IETF should not do POSIX APIs, but instead something of their 
own.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[Luca Muscariello]

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

I'm looking at TAPS too as I'm looking for a general transport API other
than TCP/UDP.

The kind of transport services we have developed in here
https://git.fd.io/cicn/ do not fit in the current API.
Full user land implementation, which seems to be accepted nowadays, but not
at all a few years back.
The API however is a hack of the INET API, which is rather obsolete, but
this is what current apps can use.
So, hope TAPS gets traction.

And yes, IPv6, absolutely. Going through IPv4 middle boxes is a nightmare.
No hope there.

And yes, flow queueing, absolutely. Flow isolation, becomes fundamental is
such a zoo, or jungle.











On Wed, Apr 4, 2018 at 10:52 AM, Mikael Abrahamsson <swmike@swm.pp.se>
wrote:

> On Wed, 4 Apr 2018, Dave Taht wrote:
>
> How dead is posix these days? Ietf does not generally do apis well.
>>
>
> POSIX nowadays is
>
> http://pubs.opengroup.org/onlinepubs/9699919799/
>
> My take on it is that the IETF should not be scared to do APIs, even
> though there is a lot of resistance still.
>
> However, the IETF should not do POSIX APIs, but instead something of their
> own.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

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

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

[Mikael Abrahamsson]

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

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

[Luca Muscariello]

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

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 <swmike@swm.pp.se>
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
>

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

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

[Marcelo Ricardo Leitner]

On Wed, Apr 04, 2018 at 01:06:22PM +0200, Luca Muscariello wrote:
> 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.

And SCTP.

> 
> 
> On Wed, Apr 4, 2018 at 12:52 PM, Mikael Abrahamsson <swmike@swm.pp.se>
> 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
> >

> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

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

[Michael Richardson]

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


Dave Taht <dave.taht@gmail.com> wrote:
    > How dead is posix these days? Ietf does not generally do apis well.

I disagree.

IETF has lore says that it doesn't do APIs well, and so it's a
self-fullfiling prophecy.  Everyone knows it's true without any actual
evidence, so nobody tries.

Who does do APIs well today?  Microsoft's API story is a disaster,
so despite decades of market dominance, their networking APIs are not
defacto standard.  While it looks like Linux does APIs well, actually,
it just does a really good job at getting the public APIs implemented.

The IPv6 BSD sockets API is a roaring success.
It's just not enough given MIF, DNSSD, IPsec, LISP, etc.  The problem
space has expanded.

The problem is getting API work funded across Google, Apple, MS, *BSD,
and Linux.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Michael Welzl]

Sent from my iPhone

> On 4 Apr 2018, at 21:23, Michael Richardson <mcr@sandelman.ca> wrote:
> 
> 
> Dave Taht <dave.taht@gmail.com> wrote:
>> How dead is posix these days? Ietf does not generally do apis well.
> 
> I disagree.
> 
> IETF has lore says that it doesn't do APIs well, and so it's a
> self-fullfiling prophecy.  Everyone knows it's true without any actual
> evidence, so nobody tries.
> 
> Who does do APIs well today?  Microsoft's API story is a disaster,
> so despite decades of market dominance, their networking APIs are not
> defacto standard.  While it looks like Linux does APIs well, actually,
> it just does a really good job at getting the public APIs implemented.
> 
> The IPv6 BSD sockets API is a roaring success.
> It's just not enough given MIF, DNSSD, IPsec, LISP, etc.  The problem
> space has expanded.
> 
> The problem is getting API work funded across Google, Apple, MS, *BSD,
> and Linux.

fwiw, apple is on board of taps and actively involved, and the neat project  ( www.neat-project.org ) made an open source library that runs on linux and bsd systems


> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
> 

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

[Marcelo Ricardo Leitner]

On Wed, Apr 04, 2018 at 09:38:02PM +0200, Michael Welzl wrote:
> 
> 
> Sent from my iPhone
> 
> > On 4 Apr 2018, at 21:23, Michael Richardson <mcr@sandelman.ca> wrote:
> > 
> > 
> > Dave Taht <dave.taht@gmail.com> wrote:
> >> How dead is posix these days? Ietf does not generally do apis well.
> > 
> > I disagree.
> > 
> > IETF has lore says that it doesn't do APIs well, and so it's a
> > self-fullfiling prophecy.  Everyone knows it's true without any actual
> > evidence, so nobody tries.
> > 
> > Who does do APIs well today?  Microsoft's API story is a disaster,
> > so despite decades of market dominance, their networking APIs are not
> > defacto standard.  While it looks like Linux does APIs well, actually,
> > it just does a really good job at getting the public APIs implemented.
> > 
> > The IPv6 BSD sockets API is a roaring success.
> > It's just not enough given MIF, DNSSD, IPsec, LISP, etc.  The problem
> > space has expanded.
> > 
> > The problem is getting API work funded across Google, Apple, MS, *BSD,
> > and Linux.
> 
> fwiw, apple is on board of taps and actively involved, and the neat
> project  ( www.neat-project.org ) made an open source library that
> runs on linux and bsd systems

Neat has a very interesting concept. If they can pull that out, it
will be very nice.