Hi Philipp, Thanks a lot for your comments! Definitely not rat-holing, you ask some quite interesting questions - it’s great to get some discussion on this!
My answers are in line: > On Jun 26, 2017, at 5:37 PM, Philipp S. Tiesel <ph...@in-panik.de> wrote: > > Hi Michael, > Hi Stein, > > I also read through the draft (now more than once) and have some questions > and comments. > I hope not to open old rat-holes with this… > > > Sec 1 (Intro) > > The number of transport features of current IETF transports is large, > and exposing all of them has a number of disadvantages: generally, > the more functionality is exposed, the less freedom a TAPS system has > to automate usage of the various functions of its available set of > transport protocols. Some functions only exist in one particular > protocol, and if an application would use them, this would statically > tie the application to this protocol, counteracting the purpose of a > TAPS system. Also, if the number of exposed features is exceedingly > large, a TAPS system might become very hard to use for an application > programmer. Taking [TAPS2] as a basis, this document therefore > develops a minimal set of transport features, removing the ones that > could be harmful to the purpose of a TAPS system but keeping the ones > that must be retained for applications to benefit from useful > transport functionality. > > I am somewhat unsure if a TAPS system really should withhold an application > from, e.g., using TCP specific features if it has strong evidence that the > other endpoint will be TCP only? Let me give you an SCTP example: "Specifying a "payload protocol-id" (handed over as such by the receiver)”. This is actually just a mechanism to send an out-of-band number that’s logically associated with an SCTP association. I wouldn’t think it’s the world’s most useful mechanism, either… but: if you use this, any chance of falling back to TCP flies out the window. I.e.: if SCTP doesn’t work, the TAPS system fails. You write about TCP; this is a bit of a special case, because it’s the protocol that we chose to be able to fall back to - so forever binding an application to TCP won’t make the TAPS system fail. It will, however, make it less flexible, so I don’t think it’s advisable. Note these are all informational documents, there’s no TAPS “police” - if you implement a TAPS system that goes against this rule this is still a good way forward! But I think having this word of caution against such protocol-specific functions here makes sense. > I agree that an application using TAPS should make use of automation when > possible to avoid ossification, but is excluding applications that need > protocol specific functionality much more dangerous as it requires a non-TAPS > API to be present to service them? I don’t know - maybe we should discuss this based on concrete cases. What functionality are you missing? To me, if possible, the better thing to do would be to express this functionality abstract enough so it doesn’t get in the way of a TAPS system’s flexibility. > This "minimal set" can be implemented one-sided with a fall-back to > TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP > receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP > sender. For systems that do not have this requirement, > [I-D.trammell-taps-post-sockets] describes a way to extend the > functionality of the minimal set such that several of its limitations > are removed. > I am glad to see that fallback is addressed, but why exclusively to TCP and > not TCP or UDP – whatever is more applicable? That’s a tricky one. At some point, when designing this, I thought of addressing both … and that would have made the draft even longer and the story even more complex. This was my main motivation for TCP-only :) Also, TCP does suit for many things - even UDP applications won’t “break” with TCP (actually some UDP apps such as Skype *do* fall back to TCP), but most TCP apps would “break” with UDP. > I also don’t see any reason why a system like post sockets shouldn’t support > fallback. If using something happy eyeballs to check what protocols are > available (biased by preference)m there is no reason why supporting a > fallback ha to limit functionality. I disagree with the second sentence, but maybe this is a misunderstanding, as there are multiple degrees of freedom here. If “fallback” is only about the protocol on the wire, not about the system on the other end, then there is no limitation: you can define pretty much any protocol you wish atop UDP. However, fallback as in the minset draft requires only a one-sided change - i.e., a minset client is able to talk to a TAPS-ignorant TCP server. post-sockets is somewhere in between: it does assume a post-socket system on both ends (e.g., to guarantee that the receiving application is informed about message boundaries), but most of it can probably be implemented with existing protocols. > Sec 2.3 (Flow Group Configuration) > > Does the "capacity profile” only apply to a flow group or can it also be > applied on a per-message basis? > If this is only intended to imply the DSCP value, a message would be a much > better scope, e.g. for protocols that multiplex multiple kinds of message > within a single flow/flow group. First: it’s not only intended to imply the DSCP value - I tried to make things a tiny bit more abstract and uniform by inventing this transport feature that encompasses the DSCP but also e.g. the choice of LEDBAT or not, or controlling Nagle. Second: conceptually I agree that a message would be a better scope if it was only the DSCP (but it isn’t - and e.g. switching to LEDBAT clearly isn’t a per-message thing), but even for the DSCP this doesn’t seem doable with TCP, or with SCTP, where the DSCP is a parameter of a “peer address”, i.e. related to an association: https://tools.ietf.org/html/rfc6458#section-8.1.12 <https://tools.ietf.org/html/rfc6458#section-8.1.12> > Same applies to more values. Does it make sense to make them configurable on > multiple levels? What do you mean? > Sec. 4 > > CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile] > [low_watermark]) > > Do these three really belong together or are this these rathe three more or > less independent configuration variables? Oh, that was just an effort to group them somehow. We could just as well have a big “CONFIGURE” call that lets you configure anything, I just felt it’s a bit more organized this way. To me, these fit together, but I don’t have a very strong opinion about this. > CONNECT (flow-id dst_addr) > > Connects a flow. This primitive may or may not trigger a > notification (continuing LISTEN) on the listening side. If a send > precedes this call, then data may be transmitted with this connect. > > PARAMETERS: > dst_addr: the destination transport address to connect to > > Might be only a knit but this looks very TCP centric for me – how would a > usage example for "UDP connect” (which is somewhat of a contradiction anyway) > – maybe I only dislike connect here… It’s not a contradiction - CONNECT just creates a context, e.g. for configuration transport features (see draft-ietf-taps-transports-usage-udp ). In the minset, a flow can also be a stream of an SCTP association, in which case opening flow #2 and #3 of an association doesn’t actually produce any effect on the wire - just as with UDP. > Maybe this also needs what types of dst_addr might take - do I have to think > this something like a sockaddr_t or as a host / service pair? The latter is > much more useful for automation. Ah, I see - “transport address” is defined in the list in the usage draft, but not in the minset draft. I think that’s a mistake, based on copying an older version of this list. Sorry! From the usage draft: *** Transport Address: the combination of an IP address, transport protocol and the port number used by the transport protocol. *** Cheers, Michael
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
