Scott Bradner wrote: > > Brian sez: > > In the intserv case, it is no different. In the diffserv case, the presumption > > is that we would use IANA-assigned, globally meaningful values, that are > > specific to a desired QOS treatment rather than to any individual traffic flow. > > The implementation details (including the DSCP value and router configurations) > > may differ from ISP to ISP, but the flow label bits convey end to end > > semantics. This is more powerful than port numbers whose semantics are poor at > > best for QOS purposes, and it works when the port numbers are invisible. > > this still begs the question > why do folk think that ISPs half way around the world would find it useful > to know what the sending computer wanted for QoS?
s/computer/customer/ If A is a customer of ISP X in some distant country, there might be (and I am only saying might be) an SLA in place that says "whenever you get a packet from or to A, with 1234 in its flow label, give it such a level of service." I'm not saying that this is especially likely or plausible, but it certainly isn't impossible. > > at least in the case of difserv if an ISP gets a DSCP there is some > implied authorization by the previous network (ISP or enterprise) - how > does authorization happen in the case of imutable globally meaningful > values? In both cases you need an SLA in place - with the upstream ISP, or with the ultimate traffic source or destination. I agree that it certainly doesn't happen because the ISP is a nice guy. > > I see no reason to believe that such a field will be any use whatsoever > in providing QoS in the Internet - and it is redundant in an enterprise > because the enterprise can decide to not change the DSCP field I bet I could construct an enterprise scenario where you could use it, but you're basically correct, the only real use is when you jump over intermediate ISPs and need a field that hasn't been changed en route. > > unless there is some hint of a way for this change to serve any useful > purpose we should just leave things as they are No, I don't agree that we can leave the vagueness in 2460. IMNSHO we should either accept the rewording we've hammered out (which carefully doesn't say anything about QOS) or change it to MBZ. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
