On Fri, Sep 14, 2018 at 12:18 AM, Michael Welzl <[email protected]> wrote:
> > 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. > All I meant was that the API is a no-op. > 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. > Thanks. >> > 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? > Not really. I guess the thing that I'm saying is that MPTCP is something that the stack could automatically decide to use, but it can't automatically decide *not* to use if the application wants that. That's what's puzzling me about "automatable" -Ekr Cheers, > Michael > >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
