Hi,
> > COMMENTS > > S 1. > > of libraries to use this transport feature without exposing it, based > > on knowledge about the applications -- but this is not the general > > case). In most situations, in the interest of being as flexible and > > efficient as possible, the best choice will be for a library to > > expose at least all of the transport features that are recommended as > > a "minimal set" here. > > > > What is the bar for the requirements here. I.e., do you believe that > > all of these can be implemented with a standard sockets API. > > I don't fully get this - it CAN be implemented atop the standard > socket API (cf. https://github.com/NEAT-project/neat > <https://github.com/NEAT-project/neat>), if that's > what you're asking? > > How do you implement limits on retransmission rates with standard sockets? It’s an SCTP feature (limiting the number of retransmissions is a part of its partial reliability, specified as one way of doing it in RFC 3758); when you fall back to TCP, you do nothing. In terms of the document, the following text in appendix A.1 says it: o Configurable Message Reliability Protocols: SCTP (..) Implementation over TCP: By using SEND.TCP and ignoring this configuration: based on the assumption of the best-effort service model, unnecessarily delivering data does not violate application expectations. Moreover, it is not possible to associate the requested reliability to a "message" in TCP anyway. Implementation over UDP: not possible (UDP is unreliable). If that seems disappointing: the goal of this document was to describe what can be done while being protocol-independent and allowing to fall back to TCP, or even UDP in some cases. The minute you write code that checks if configuring retransmission limits is possible, you need to implement an exception for the TCP case. I’m not saying this is bad design at all, it just wasn’t the goal of the minset. This doesn’t mean that a TAPS system needs to be limited in this way - it’s just the minimum you can expect from it. > > S 3. > > > > Based on the categorization, reduction, and discussion in Appendix A, > > this section describes a minimal set of transport features that end > > systems should offer. The described transport system can be > > implemented over TCP. Elements of the system that are not marked > > with "!UDP" can also be implemented over UDP. > > > > Does this mean over native UDP with no other session protocol. Because > > you can have TCP over UDP. > > Native; we added a disclaimer about this at the end of the introduction. > > > > > S 3.2. > > multiplexed as streams on a single SCTP association when SCTP may not > > be available). The transport system must therefore ensure that > > group- versus non-group-configurations are handled correctly in some > > way (e.g., by applying the configuration to all grouped connections > > even when they are not multiplexed, or informing the application > > about grouping success or failure). > > > > How do you group connections in TCP? Or is this text saying it > > doesn't? > > The text doesn't make any assumption about this being possible with > anything but SCTP. This being said, I can't resist offering an answer > (but that's out of scope of minset): > https://ieeexplore.ieee.org/document/8406887/ > <https://ieeexplore.ieee.org/document/8406887/> > > This is behind a paywall, but it appears to just be about congestion control, > so perhaps there is some confusion about "grouping". I had read that as > application visible grouping. Is that not what you mean? Sorry for the link problem; it IS application visible grouping, with prioritization. There’s also this draft: https://tools.ietf.org/html/draft-welzl-tcp-ccc <https://tools.ietf.org/html/draft-welzl-tcp-ccc> and we have FreeBSD code doing this. Safiqul has various material here: http://safiquli.at.ifi.uio.no/tcp-ccc/ <http://safiquli.at.ifi.uio.no/tcp-ccc/> I think we're diverging from the minset discussion, so I’ll stop here - but if this really interests you, tell me: I’d be very happy to discuss it further and send you the paper. I’d love for someone to use this! Since you mentioned TCP over UDP before - that’s actually one of the things we implemented, to ensure that flows traverse the same path. > > S 7.2. > > > > o Disable MPTCP > > Protocols: MPTCP > > Automatable because the usage of multiple paths to communicate to > > the same end host relates to knowledge about the network, not the > > application. > > > > I don't think I understand how this is automatable. Is the theory that > > the host auto-negotiates MPTCP? But what if the app doesn't want it no > > matter what. > > Then the application wants more than what this design of strictly > "application-specific knowledge" is giving it. That's the trade-off here - > there may be many reasons for applications to want things beyond this > document, but if we weren't strict about these limitations, this would > have hardly become a "minimal set". > > That's reasonable, but it seems like a somewhat confusing definition. What is it that’s confusingly defined? “application-specific knowledge”? “Automatable"? Happy to fix if you tell me what. Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
