Scott Bradner wrote: > > Brian sez: > > Disagree. The QOS usages are clear and well-defined. The others are all > > pretty dumb. > > I disagree on both parts of this > > Brian thinks the "other" uses for the flow label are dumb, I happen to agree > but the people who made the proposals did not think they were dumb - I > do not claim to have perfect knowledge of all things
Neither do I. I do have reasons for the statement I made, but since there have been no proposals that I've seen for the other uses (except that the CATNIP-like label swapping idea morphed into MPLS) it doesn't seem worth analysing vague ideas. > > Brian also says that the QOS usages are clear and well-defined, I see > no reason to think this is the case I think this has been covered adequately in other messages for Intserv and Diffserv, with specific detail. > > The issues of how to use Diffserv and what interdomain QOS mean are > complex and not captured by the 24 bits the WG has in play Nobody said they are. The issue is getting something minimal and unambiguous into the IPv6 spec before it's too late. > > Who can say that it is even useful to know half way around the world > what a sender wanted for QoS when there is no way to know if that sender > had authority or local priority to ask for that QoS and, at least at this > time, there is no way for the remote ISP to do settlements to get > paid for treating the packet in any way other than best effort These issues will never be resolved unless we have the bare bones of a mechanism to build on. > > I think that a lot of work needs to be done on what QoS means in > an inter-domain world before we can even guess if e2e QoS has any meaning. Indeed, for the general case. But there are scenarios involving relatively small sets of sites and ISPs where we can see how to construct e2eQOS. > > I think Tony's proposed text is nice but it is only a cellophane fig > leaf over the fact that we have no idea how to "do" QoS in the real-world > Internet. I see no particular advantage to adopting the text. I think it is better than MBZ text simply because it sets some boundary conditions that we can work with. MBZ text just stops all work on this topic for the foreseeable future. > > Scott > > (ps - for a data point in the mutability camp, Cisco IP phones are designed > with two Ethernet jacks, one to connect to the wall jack - the desktop > machine is to be plugged into the other. The phone clears the DSCP on > all packets it forwards from the desktop and sets the DSCP to 5 on all > of its own data packets - I assume to protect the infrastructure from > applications on the desktop that might overwhelm the net with packets > marked as high priority) Right, and this is a hangover from the days before the EF code point was assigned, and we were advising experimenters to use Precedence 5 for EF tests. 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] --------------------------------------------------------------------
