Hi, Thanks a lot for reading and commenting!
> On Mar 24, 2017, at 8:29 AM, Gorry Fairhurst <[email protected]> wrote: > > This looks like good progress. A few very specific comments below: > > --- > I see phrase: > " Because QoS is out of scope of TAPS, this document assumes a "best > effort" service model [RFC5290], [RFC7305]. " > > I'm not sure we need to state this. Although I agree that TAPS will not > propose new QoS techniques, the service provided by TAPS is, I think, also > not confinded to "best effort”. Hmm... I was also thinking about the behavior of the actual TAPS system in the end host, where you may ask for something but might not get it (e.g. requested unordered message delivery might turn into ordered bytestream delivery). So for now, best effort is indeed the underlying assumption - e.g. the proposed “capacity profile” doesn’t come with any guarantees, it *might* set the DSCP for you, and that *might* have a certain effect. If we take that assumption away, the proposed system would be different - it would have to fail and say “no, sorry” more often, which I don’t think is a good way ahead. What do you think? > --- > I am not sure that IP options from UDP are entirely automatbale. Per-packet > IP options could be related to application use of the network, and I think > this would require some form of API interaction. > > — We called everything that doesn’t require application-specific knowledge (knowledge that only applications have) “automatable”. So my first question is: what is it that only an application knows, and that influences the choice of IP options? (generally though I’d be fine with introducing some transport features that help the system do its automation - the conclusion talks about this, using the choice of paths as an example). > I see LE service as something interesting, yet this does not exactly fit the > rest of the draft. The cited reference is to a DiffServ PHB, and the LEDBAT > referenced is a transport protocol mechanism, not a protocol. I'm not sure > this inclusion is justified in the current tetx. True that LEDBAT is a mechanism, not a protocol - but we specifically wanted to include this in TAPS, which is why the charter mentions “congestion control mechanisms", in item 1: "Define a set of Transport Services, identifying the services provided by existing IETF protocols and congestion control mechanisms.” I addressed this in the usage draft by making ** Enable and configure a "Low Extra Delay Background Transfer” ** a CONNECTION.MAINTENANCE feature, i.e. something you use to configure a connection. This seems to me to be the most likely implementation - it also matches how e.g. the CDG TCP congestion control mechanism (which was found to exhibit LBE’ behaviour) works. The LBE stuff in minset comes from the usage draft. > --- > Abort without delivering... > > Abortis currently specified for SCTP and TCP. If one assumes the bound > semantics for UDP(Lite) this also seems also the correct primitive for > UDP(Lite. > > Should this ID specify a connect primitive also for bound use of UDP(Lite)? Okay, I think you found an error here: Both “connect" and “close" primitives exist in draft-ietf-taps-transports-usage-udp, and were taken over into step 2 of draft-ietf-taps-transports-usage. Step 3, which is where the transport features in minset come from, misses UDP(-Lite) under “close” ! As I was writing the more elaborate description of “close” in step 3, "Close after reliably delivering all remaining data, causing an event informing the application on the other side”, I felt I really couldn't place UDP(-Lite) there, I think this is how it was dropped. UDP(-Lite) would have survived if this would have been called “ABORT”, and here’s the mistake: semantically, as you identify here, UDP(-Lite)’s “close” is really equivalent to “abort”, not “close”. I can fix this in the next update of the -usage draft, and adjust the -minset draft accordingly. > --- > > What should be said about SCTP usage of IP OPTIONS? I would have expected if > the endpoint network layer set these, they would also work for SCTP? Look for “SET_IP_OPTIONS” in draft-ietf-taps-transports-usage-udp: your text here cites RFC 1122 saying that UDP offers access to this functionality. I haven’t found anything equivalent for SCTP. It may exist in implementations? I’m not sure how this is done - maybe there’s a general call to configure IP options for all outgoing packets on an interface, or to a certain destination? If so, this would be worth pointing out at this point, when it comes to discussing possible fall-backs. > --- > > Finally, > > I think I can agree the argument that UDP(Lite) message handling is different > to SCTP. > > --- > > Gorry Thanks again! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
