Hi Michael,
> On 26. Jun 2017, at 23:00, Michael Welzl <mich...@ifi.uio.no> wrote: > > 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 >> <mailto: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. Ok - this case looks as useful as TCP urgent data – I agree recommending against using such mechanisms. > 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 think this is a little more complex… If you want a TAPS system to fully replace other Socket APIs, I assume it should also make protocol features available, that are nor portable across protocols. I agree that these features are a) not part of a minimal set b) no “first class citizens” c) recommended against using. The question is whether this discussion should go into this or another draft. >> 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. I definitely see OOB mechanisms as discussed above and path management in MPTCP and SCPT. The latter is a good candidate for abstract terms and automation, but there might also be use cases for which a more concrete, protocol independent API to bind data to certain paths is needed. For OOB mechanisms, there might be use of some special flags to the send_frame and recv_frame calls that are a) protocol specific, b) cause an error if called on a flow using the wrong protocol and c) are recommended against using. >> 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. For doing this, you would have to move the reliable/unreliable decision up to the "Flow Group” level… But finally, I guess it is needed at both levels. In case “unreliable” it is set at "Flow Group” level, all messages will be unreliable, if set at message level, the single message is sent unreliable if supported by the underlying protocol. >> 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. Oh, I never read that from the Post Socket publications. But I guess we should discuss this with Brian how much he has Post Socket to “Legacy” communication in mind. >> 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? I primarily had the reliability issue in mind, but as I am about to publish a draft on how to compose multipath aware protocol stacks, I fear almost all transport features can be implemented at almost all levels… >> 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. Fine - I just know too many people that scream when mentioning UDP and connect together ;-) >> 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. > *** Ok - thanks for clarifying - so no name resolution and endpoint selection in the minimal mindset? AVE! Philipp S. Tiesel / phils…
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
