If you don't believe in signaled QoS, you don't
believe in any use of a flow label qua flow label.
Fine; many people don't. For those people, you
have the DSCP and the luck of the draw. It's
infinitely mutable, etc, etc. Be happy because
there's nothing to be done here.
And XP can make flow labels along with DSCP's as
soon as the current or next gen worm is done
rewriting their kernels.
Mike
Perry E. Metzger writes:
>
> Michael Thomas <[EMAIL PROTECTED]> writes:
> > > 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.
> >
> > UDP ports in ESP encrypted payloads. Tunnels inside
> > tunnels inside tunnels inside tunnels. New protocols
> > which may not even have abstracted ports. New Protocols
> > period. TCAM widths that lose to Moore's Law.
> >
> > Need I go on?
>
> Yes, you need to go on. For the most part, I'm not sure this is going
> work out. As I note, we've already deployed. Windows XP and such
> aren't going to be obeying any of this, so the routers have to look at
> the contents of the packets anyway. For many of the protocols we're
> dealing with here (such as tunnels inside tunnels) it isn't clear
> there is a clean way for the mechanisms to actually extract an
> appropriate flow label under the new definition, and, most
> importantly, as I noted earlier, you can't figure out how to
> prioritize traffic using the flow label anyway.
>
> > > 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.
> >
> > RSVP is your friend.
>
> The century that RSVP is implemented and deployed I'm sure it will be
> used, at least once in a while. (I don't expect our descendants to see
> that day, but...)
>
> Meanwhile, in practice what people tend to do on things like congested
> leaf routers is prioritize based on traffic type.
>
> --
> 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]
--------------------------------------------------------------------
