* [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 [not found] <tag:www.oreilly.com, 2018-04-02:/ideas/four-short-links-2-april-2018@localhost.localdomain> @ 2018-04-02 12:46 ` David Collier-Brown 2018-04-03 11:54 ` Jesper Louis Andersen 0 siblings, 1 reply; 22+ messages in thread From: David Collier-Brown @ 2018-04-02 12:46 UTC (permalink / raw) To: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-02 12:46 ` [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 David Collier-Brown @ 2018-04-03 11:54 ` Jesper Louis Andersen 2018-04-03 12:14 ` Jonathan Morton 0 siblings, 1 reply; 22+ messages in thread From: Jesper Louis Andersen @ 2018-04-03 11:54 UTC (permalink / raw) To: davecb; +Cc: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 11:54 ` Jesper Louis Andersen @ 2018-04-03 12:14 ` Jonathan Morton 2018-04-03 12:35 ` Mikael Abrahamsson 0 siblings, 1 reply; 22+ messages in thread From: Jonathan Morton @ 2018-04-03 12:14 UTC (permalink / raw) To: Jesper Louis Andersen; +Cc: davecb, bloat > 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 12:14 ` Jonathan Morton @ 2018-04-03 12:35 ` Mikael Abrahamsson 2018-04-03 14:27 ` Michael Welzl 0 siblings, 1 reply; 22+ messages in thread From: Mikael Abrahamsson @ 2018-04-03 12:35 UTC (permalink / raw) To: Jonathan Morton; +Cc: Jesper Louis Andersen, bloat 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 12:35 ` Mikael Abrahamsson @ 2018-04-03 14:27 ` Michael Welzl 2018-04-03 14:48 ` Jesper Louis Andersen 0 siblings, 1 reply; 22+ messages in thread From: Michael Welzl @ 2018-04-03 14:27 UTC (permalink / raw) To: Mikael Abrahamsson; +Cc: Jonathan Morton, bloat 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 14:27 ` Michael Welzl @ 2018-04-03 14:48 ` Jesper Louis Andersen 2018-04-03 15:04 ` Jim Gettys 2018-04-03 16:14 ` Michael Welzl 0 siblings, 2 replies; 22+ messages in thread From: Jesper Louis Andersen @ 2018-04-03 14:48 UTC (permalink / raw) To: Michael Welzl; +Cc: Mikael Abrahamsson, Jonathan Morton, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 14:48 ` Jesper Louis Andersen @ 2018-04-03 15:04 ` Jim Gettys 2018-04-04 12:45 ` Jesper Louis Andersen 2018-04-03 16:14 ` Michael Welzl 1 sibling, 1 reply; 22+ messages in thread From: Jim Gettys @ 2018-04-03 15:04 UTC (permalink / raw) To: Jesper Louis Andersen; +Cc: Michael Welzl, Jonathan Morton, bloat [-- 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 than 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 15:04 ` Jim Gettys @ 2018-04-04 12:45 ` Jesper Louis Andersen 2018-04-04 13:39 ` David Collier-Brown 0 siblings, 1 reply; 22+ messages in thread From: Jesper Louis Andersen @ 2018-04-04 12:45 UTC (permalink / raw) To: Jim Gettys; +Cc: Michael Welzl, Jonathan Morton, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 12:45 ` Jesper Louis Andersen @ 2018-04-04 13:39 ` David Collier-Brown 0 siblings, 0 replies; 22+ messages in thread From: David Collier-Brown @ 2018-04-04 13:39 UTC (permalink / raw) To: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 14:48 ` Jesper Louis Andersen 2018-04-03 15:04 ` Jim Gettys @ 2018-04-03 16:14 ` Michael Welzl 2018-04-04 7:01 ` Mikael Abrahamsson 2018-04-04 7:42 ` Dave Taht 1 sibling, 2 replies; 22+ messages in thread From: Michael Welzl @ 2018-04-03 16:14 UTC (permalink / raw) To: Jesper Louis Andersen; +Cc: Mikael Abrahamsson, Jonathan Morton, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 16:14 ` Michael Welzl @ 2018-04-04 7:01 ` Mikael Abrahamsson 2018-04-04 7:42 ` Dave Taht 1 sibling, 0 replies; 22+ messages in thread From: Mikael Abrahamsson @ 2018-04-04 7:01 UTC (permalink / raw) To: Michael Welzl; +Cc: Jesper Louis Andersen, Jonathan Morton, bloat [-- 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-03 16:14 ` Michael Welzl 2018-04-04 7:01 ` Mikael Abrahamsson @ 2018-04-04 7:42 ` Dave Taht 2018-04-04 7:55 ` Michael Welzl ` (2 more replies) 1 sibling, 3 replies; 22+ messages in thread From: Dave Taht @ 2018-04-04 7:42 UTC (permalink / raw) To: Michael Welzl; +Cc: Jesper Louis Andersen, Jonathan Morton, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 7:42 ` Dave Taht @ 2018-04-04 7:55 ` Michael Welzl 2018-04-04 8:53 ` Mikael Abrahamsson 2018-04-04 8:52 ` Mikael Abrahamsson 2018-04-04 19:23 ` Michael Richardson 2 siblings, 1 reply; 22+ messages in thread From: Michael Welzl @ 2018-04-04 7:55 UTC (permalink / raw) To: Dave Taht; +Cc: Jesper Louis Andersen, Jonathan Morton, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 7:55 ` Michael Welzl @ 2018-04-04 8:53 ` Mikael Abrahamsson 0 siblings, 0 replies; 22+ messages in thread From: Mikael Abrahamsson @ 2018-04-04 8:53 UTC (permalink / raw) To: Michael Welzl; +Cc: Dave Taht, bloat, Jonathan Morton [-- 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 7:42 ` Dave Taht 2018-04-04 7:55 ` Michael Welzl @ 2018-04-04 8:52 ` Mikael Abrahamsson 2018-04-04 9:56 ` Luca Muscariello 2018-04-04 19:23 ` Michael Richardson 2 siblings, 1 reply; 22+ messages in thread From: Mikael Abrahamsson @ 2018-04-04 8:52 UTC (permalink / raw) To: Dave Taht; +Cc: Michael Welzl, bloat, Jonathan Morton 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 8:52 ` Mikael Abrahamsson @ 2018-04-04 9:56 ` Luca Muscariello 2018-04-04 10:52 ` Mikael Abrahamsson 0 siblings, 1 reply; 22+ messages in thread From: Luca Muscariello @ 2018-04-04 9:56 UTC (permalink / raw) To: Mikael Abrahamsson; +Cc: Dave Taht, Jonathan Morton, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 9:56 ` Luca Muscariello @ 2018-04-04 10:52 ` Mikael Abrahamsson 2018-04-04 11:06 ` Luca Muscariello 0 siblings, 1 reply; 22+ messages in thread From: Mikael Abrahamsson @ 2018-04-04 10:52 UTC (permalink / raw) To: Luca Muscariello; +Cc: Dave Taht, Jonathan Morton, bloat 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 10:52 ` Mikael Abrahamsson @ 2018-04-04 11:06 ` Luca Muscariello 2018-04-05 0:04 ` Marcelo Ricardo Leitner 0 siblings, 1 reply; 22+ messages in thread From: Luca Muscariello @ 2018-04-04 11:06 UTC (permalink / raw) To: Mikael Abrahamsson; +Cc: Dave Taht, Jonathan Morton, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 11:06 ` Luca Muscariello @ 2018-04-05 0:04 ` Marcelo Ricardo Leitner 0 siblings, 0 replies; 22+ messages in thread From: Marcelo Ricardo Leitner @ 2018-04-05 0:04 UTC (permalink / raw) To: Luca Muscariello; +Cc: Mikael Abrahamsson, Jonathan Morton, bloat 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 7:42 ` Dave Taht 2018-04-04 7:55 ` Michael Welzl 2018-04-04 8:52 ` Mikael Abrahamsson @ 2018-04-04 19:23 ` Michael Richardson 2018-04-04 19:38 ` Michael Welzl 2 siblings, 1 reply; 22+ messages in thread From: Michael Richardson @ 2018-04-04 19:23 UTC (permalink / raw) To: Dave Taht; +Cc: Michael Welzl, bloat, Jonathan Morton [-- 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 --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 19:23 ` Michael Richardson @ 2018-04-04 19:38 ` Michael Welzl 2018-04-05 0:08 ` Marcelo Ricardo Leitner 0 siblings, 1 reply; 22+ messages in thread From: Michael Welzl @ 2018-04-04 19:38 UTC (permalink / raw) To: Michael Richardson; +Cc: Dave Taht, bloat, Jonathan Morton 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 [ > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 2018-04-04 19:38 ` Michael Welzl @ 2018-04-05 0:08 ` Marcelo Ricardo Leitner 0 siblings, 0 replies; 22+ messages in thread From: Marcelo Ricardo Leitner @ 2018-04-05 0:08 UTC (permalink / raw) To: Michael Welzl; +Cc: Michael Richardson, Jonathan Morton, bloat 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-04-05 0:08 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <tag:www.oreilly.com, 2018-04-02:/ideas/four-short-links-2-april-2018@localhost.localdomain> 2018-04-02 12:46 ` [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 David Collier-Brown 2018-04-03 11:54 ` Jesper Louis Andersen 2018-04-03 12:14 ` Jonathan Morton 2018-04-03 12:35 ` Mikael Abrahamsson 2018-04-03 14:27 ` Michael Welzl 2018-04-03 14:48 ` Jesper Louis Andersen 2018-04-03 15:04 ` Jim Gettys 2018-04-04 12:45 ` Jesper Louis Andersen 2018-04-04 13:39 ` David Collier-Brown 2018-04-03 16:14 ` Michael Welzl 2018-04-04 7:01 ` Mikael Abrahamsson 2018-04-04 7:42 ` Dave Taht 2018-04-04 7:55 ` Michael Welzl 2018-04-04 8:53 ` Mikael Abrahamsson 2018-04-04 8:52 ` Mikael Abrahamsson 2018-04-04 9:56 ` Luca Muscariello 2018-04-04 10:52 ` Mikael Abrahamsson 2018-04-04 11:06 ` Luca Muscariello 2018-04-05 0:04 ` Marcelo Ricardo Leitner 2018-04-04 19:23 ` Michael Richardson 2018-04-04 19:38 ` Michael Welzl 2018-04-05 0:08 ` Marcelo Ricardo Leitner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox