[this also responds to Scott's comments, I think] "Perry E. Metzger" wrote: > > Michael Thomas <[EMAIL PROTECTED]> writes: > > Perry E. Metzger writes: > > > > Sorry, the SPI is no good for diffserv classification > > > > because it has no semantics. > > > > > > Neither does the flow label. Both are just a number that can be used > > > to distinguish a bunch of traffic flowing between two hosts from other > > > traffic flowing between two hosts. Neither has any semantics beyond > > > that. > > > > Bzzt. You're overloading semantics. SPI's enumerate > > the set of packets for which a given security policy > > applies. That may have exactly zero to do with the > > QoS policies you'd like to apply. > > In the scheme proposed, flow labels just enumerate a set of packets > that a host has chosen to designate as a "flow" because, say, they're > all using the same TCP socket -- which may also have exactly zero to > do with the QoS policies you'd like to apply. How is it any different > than the SPI situation?
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. > > > > > I didn't say it makes no difference. I said that the difference is more > > > > likely to be in cost and waste heat than in speed. > > > > > > Given that the manufacturers who are doing this are already building > > > the transistors in to walk the header chain... > > > > By all means, let's just ignore silicon considerations. > > Moore's Law trumps all, obviously. > > If they have to build tuple extraction into the hardware anyway to > deal with the implementations that don't do flow labels (i.e any > deployed in the next few years), how can we claim that we're going to > get around people having to build hardware? Given that several vendors > have already designed the hardware, how are we going to be helping? Hardware gets updated. The point of giving the flow label a clear definition is to allow hardware designers to build classifiers that include the flow label as one of the fields used for line-speed classification. What the next level up in the hardware/firmware/software does with the classified packets is a separate question. Brian > > -- > 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] --------------------------------------------------------------------
