> On 13 Sep 2018, at 20:24, Eric Rescorla <[email protected]> wrote: > > > > 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?
Exactly - though "pretends to implement it" is maybe not how it would put it: no promises are made. An application says "these messages can be out-of order", or "these connections really belong together, with the following priorities between them", but the priorities are just a hint and might be ignored, and the messages may arrive in-order, nobody promised that there would NOT be ordering. On TCP coupling: > I'd love to see the paper. I'll follow up in a separate email, with TAPS in cc because people there might find it interesting, but removing the IESG to reduce noise. >> > 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. Okay, so this is what we have in the text: " The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be utilized by a transport system on its own without involving the application are called "Automatable". " and "application-specific knowledge" is defined as "knowledge that only applications have." I'm guessing that the issue that you have with "automatable" is that it sounds too much as if the application's input really isn't needed here, no matter what. I'd like to use a "weaker" word in that sense... because of that, we once called it "Potentially automatable", but then that was too long and clumsy. Do you have any suggestions? Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
