On Thu, Sep 13, 2018 at 11:02 AM, Michael Welzl <[email protected]> wrote:
> 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), 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. > I'm not disappointed, I'm just trying to figure out how to think about this API and its requirements. What does it mean to implement this API when you have a transport which doesn't support the feature? Just that you have an affordance that pretends to implement it but doesn't? > 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/ > > > 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 > and we have FreeBSD code doing this. Safiqul has various material here: > 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. > I'd love to see the paper. > > > 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. > Automatable, I think. -Ekr > Cheers, > Michael > >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
