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 Brian also says that the QOS usages are clear and well-defined, I see no reason to think this is the case 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 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 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. 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. 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) -------------------------------------------------------------------- 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] --------------------------------------------------------------------
