Perry, really, these questions have been asked and answered a dozen times.
I'm not getting at you personally but I am getting very tired of this discussion going round and round. We (those of use who've been thinking about QOS for some years in Intserv, Diffserv and elsewhere) didn't come along with a proposal to clarify the e2e semantics of the flow label in a vacuum. Let's either clarify them, as in the one para summary that Tony Hain sent a few days ago, or simply write the field off as reserved, in which case IPv6 will have no advantage of IPv4 for QOS purposes. Brian "Perry E. Metzger" wrote: > > Am I correct in saying that, at this point, the flow label is at most > a way for intermediate routers to avoid layer violations, since a flow > is immutable and is properly given as a <srcaddr,dstaddr,flownum> tuple? > > One must ask what kind of layer violations this is intended to > stop, and what the purpose of those layer violations is. Generally > speaking, routers only reach in to the lower layers to determine how > to differentiate traffic between two hosts for purposes of > prioritization. > > If it is intended to stop routers looking at the different layers to > prioritize traffic, it is a failure, since the flow label tells an > intermediate router nothing it needs to know to prioritize traffic > other than "this is flow #N". You can't decided "hmm, interactive > traffic -- better bump that above bulk file transfer" based on the > flow label. At best, you can use the flow label for doing something > like penalizing flows with non-friendly flow control > characteristics. > > Is that the entire goal? To label flows so that they can be penalized? > Is there any other possible use of the field as defined by the proposal? > > If that's all we're gaining here, seems like a lot of mechanism for a > pretty small effect -- especially since at this point, there is no > chance of getting the overwhelming bulk of the world's v6 hosts to > insert such a label for many years -- XP and friends have already > shipped -- so your ASICs still need to know how to unwrap the TCP/UDP > headers anyway. > > Perry > -- > Perry E. Metzger [EMAIL PROTECTED] > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.com/ -------------------------------------------------------------------- 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] --------------------------------------------------------------------
