Re: [Taps] Review of draft-trammell-taps-post-sockets-03

[Michael Welzl <[e-mail]>]

> On Nov 11, 2017, at 10:06 AM, Tommy Pauly <[e-mail]> wrote:
> 
> Hi Michael,
> 
> Just a couple initial notes that may help:
> 
> - The version diff you should look at is between -01 and -03. -02 is the same as -03, but had a typo.
> 
> - You've mentioned previously that you thought that Post requires both peers to use that API. That is absolutely not the case in any way. Having implemented Post myself, I am only communicating to "legacy" servers that know nothing about Post. I think this fundamental understanding needs to be cleared up before coming to any conclusions. We can discuss during the WG.

Oh?!  That would be fantastic!!  But I stumbled over a number of things that require a system on the other side, or they just couldn’t happen (like the “carrier forking” notification I quoted below - but there were more). If you say you can talk to a “legacy” server that knows nothing about Post, WHAT does that server speak? Legacy which protocol?  Maybe it’s just a matter of me thinking TCP, and you thinking TLS… dunno! Tell me   :)


> - The point of the API is to give the shape of the application interaction, which is why you find it general. I believe that many of the protocol-specific options like you mention (disabling Nagle, retransmissions, etc) don't belong to this main abstract API draft, but to a different document that goes into how to configure options that can be used for setups like TCP/UDP. Again, in my implementation of Post, all of these options exist as part of the Configuration object mentioned in the draft. However, as I'll discuss in the WG, I believe that the general shape of the API needs to be defined to be more-forward looking than just what we've specified with the minset for TCP/UDP/SCTP. Essentially, these become a set of Configuration options that can be used, but as transport protocols continue to evolve (and when we need more protocol-specific options), we need to be able to expand. Certain aspects of the minset, like the connection state management, are of course general and common enough to be part of the highest level of API description.

It’s clear to me that we want a higher abstraction level than what the list from minset has - e.g., rather than a DSCP value, it would be better to specify general requirements (low latency or such) for a carrier. Rather than saying “disable Nagle”, we could also say “ low latency, even if it comes at the cost of some overhead” - we do such things in the NEAT API too. You’re focused on the interaction with the application (e.g. callback-based instead of traditional socket-style) - which is fine, but I think doesn’t have much to do with the actual protocol choice.

As for being more forward-looking, I wonder what the new transport features are that we’re missing out on (things that apps really see). I follow QUIC from a slightly too large distance (I simply run out of cycles there :(  ), but so far I’m not sure there’s anything we’d be missing  (but that’s maybe also because I’m not an HTTP/2 expert either). Except security of course, but there the argument is perhaps that it’s enough to consider falling back to TLS?

As for how you represent Nagle etc. in your code, that sounds good to me, but I see an issue in that so much transport functionality is simply not covered by the draft. E.g., the packet sizes / fragmentation thing is important too … yes that’s lower level stuff, but UDP-based applications will only get inefficient if they don’t get this information exposed, which risks having app programmers move to the old ways again IMO.

So, the general design approach of post-sockets is IMO fine, but what I’m missing is a long section with the nitty-gritty details on how such a system would really be implemented (not the happy eyeballing bit, this is fine to be elsewhere - but “how would this work with current protocols”). If I was to implement it from the current draft, I’d have a ton of question marks - e.g. the draft convinced me that there must be a system on both sides (this issue is also not discussed in the draft).

Cheers,
Michael