On 26/03/2017, 13:59, Michael Welzl wrote:
On Mar 26, 2017, at 12:13 PM, Gorry (erg)<go...@erg.abdn.ac.uk> wrote:
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.
But not even guaranteeing that packets will be marked would go to far? Or
wouldn’t it?
It clearly doen't help deploy diffserv if your local system bleaches the
DCSP value to zero. That happens though. So we need to live with that.
I'd therefore say it is OK.
(Just checking - because I think we could make the system guarantee that, as all
transports allow setting the DSCP; it was just my decision to combine DSCP-setting with a
few other things together and call them "capacity profile", but that’s
certainly up for debate).
That's more interesting to debate.
The words in the charter say "
Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds like a
plea not to redesign NSIS RSVP etc…
That would be my interpretation too.
Cheers,
Michael
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
Gorry
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
