Hi, I’m cutting some stuff (things that we just seem to agree about) away and answering in line again:
>> 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. But it’s a “minimum set”, so it really *is* okay to go beyond, as long as people are aware about the pro’s and con’s. Anyway, maybe there’s an alternative solution. My suggestion would be: for any functionality that we’re really missing and that would create a protocol dependency, can we try to raise the abstraction level just enough to avoid the TAPS system coming back and saying “sorry, I can’t” ? E.g.: “Pick interfaces X and Y” is something that not every protocol can do. Since it relates to system-wide or network-related information (isn’t really application-specific), minset says this could be automatized. However, giving information about the app behavior like you propose in the socketintents draft can clearly help a TAPS system make the best decision about the interface choice, and it’s only advisory information - if a TAPS system just ignores it, e.g. because MPTCP isn’t available, nothing bad will happen. >>> 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, … indeed. > but there might also be use cases for which a more concrete, protocol > independent API to bind data to certain paths is needed. … well yes, perhaps… but maybe only advisory, without guaranteeing success? These things take away freedom to automatize; I’d expect developers of TAPS systems to add some such things anyway if they truly want them, but *recommending* them… ? > 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. So what OOB mechanism are you missing? I’m a bit confused about this bit, you wrote “OOB mechanisms as discussed above” but this discussion featured us agreeing that one particular feature isn’t useful. So… ? >>> 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. Yes and yes! As I wrote in my answer to Theresa, that’s clearly a mistake in the minset, and I’ll fix it - thanks for this catch! >>> 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. Well, that post sockets assumes a system on both ends was my understanding after the last meeting (I think this was a side conversation with Tommy, though, not the open TAPS session). Either way, it’s implicitly clear because it just wouldn’t work without a TAPS-system on both ends (or fall back badly, basically saying “you can’t get this here, all you get is a stream” - which is pretty much the same as saying “sorry, only TCP here”, in which case we haven’t really achieved anything in terms of being protocol-independent). I agree that this should be made clear in the post-sockets draft. >>> 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… Thanks again for the reliability catch. I’m looking forward to this other draft, I’m interested in what this is. As long as it can be made to work with existing protocols it would seem in scope to me... >> *** >> 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? It’s just a set, not really a mindset :-) :-) :-) Right, no name resolution (and, with it, remote endpoint selection) because it’s not strictly a mechanism of the protocols that we have used as a basis (btw, we do this in NEAT - but it’s not in the minset). As for local endpoint selection, see https://tools.ietf.org/html/draft-gjessing-taps-minset-05#appendix-A.1.1 <https://tools.ietf.org/html/draft-gjessing-taps-minset-05#appendix-A.1.1> / AVAILABILITY: listen allows 1 specified local interface with all protocols, and all local interfaces too. Only SCTP allows listening on only a specific subset of interfaces. It was a decision to remove this filter and say “any” - we could have said “any, or 1 interface only” if this is really useful… again the logic in removing the “1 interface” case was to say that this choice isn’t application-specific. Cheers, Michael
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
