This reply is just about the DSCP and QoS. Everything you say about TAPS trying to set DSCP values seems consistent with normal diffserv use to me: Just because an app sets a DSCP does not mean the actually sent packets are assigned a PHB along the path, it simply marks them for this treatment, and packets may also be remarked or dropped. Since there are no guarentees, there is no need for a primitive telling an app it did not get what it hoped for. So to me, this is normal Diffserv QoS treatment. No guarentees.
The words in the charter say " Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds like a plea not to redesign NSIS RSVP etc... Gorry On 26 Mar 2017, at 06:14, Michael Welzl <[email protected]> wrote: >> 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 confined 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? > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
