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? > > > 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? -- 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] --------------------------------------------------------------------
