I certainly don't care about the pseudo-random requirement for unique-per-host
opaque flow labels, but if we agree that the flow label may be used for diffserv
then it has to have semantics (i.e. it is not an opaque value). For that I am sure
we need the MSB as a flag bit, so that a classifier can tell whether it is looking
at an opaque value or at a value with semantics.
Brian
[EMAIL PROTECTED] wrote:
>
> Brian,
>
> Let's then just say that it would be architecturally better to only have one
> format that satisfies all the needs. With better I mean things like less
> text in the specification, simpler implementations, less bugs, better
> interoperability etc.
>
> At this point no-one has established that there is a need or a requirement
> for multiple formats of flow labels. You and Alex have brought up a
> requirement that the flow label value needs to be somehow constant for the
> diffserv for a form of MF classification for diffserv usage. The traditional
> intserv has no requirement to the specific value being used, as the value is
> being explicitly signaled.
>
> It seems that both the old ("intserv") and new ("diffserv") requirements can
> be met with single flow label format (current format with no pseudo-random
> requirement).
>
> Earlier it has been thought that the pseudo-random nature of the flow label
> would make lookups easier by allowing the flow label to be used as a hash as
> such. There are some specific difficulties with this, however:
>
> 1) Routers can not know how good pseudo random numbers the flow-labels
> injected by hosts are in practice. Bad pseudo random numbers used by large
> class of hosts could constitute a kind of DoS attack against router
> implementations relying on the pseudo-random number nature of the flow
> label. [Maybe someone actually implementing look-ups on hardware based on
> the flow label could bring additional light on this matter (Alex?)]
>
> 2) If there is an alternative format, that is not pseudo-random (as being
> proposed), the routers will have to implement look-ups that function
> efficiently with that format. Since we do not know what portion of the
> traffic in the future would use this non-pseudo-random format, the
> implementations have to assume that all traffic can be labeled with this
> alternative format.
>
> It follows that there is no additional benefit of the pseudo-random nature
> of the original format. Therefore it would be best to combine these formats
> into one, that is non-pseudo-random. I.e. the current format with no
> pseudo-random requirement. This would present the minimal change to the
> current specification. Also, current (intserv) implementations could keep on
> using the current pseudo-random numbers without breaking anything.
>
> Jarno
>
> > -----Original Message-----
> > From: ext Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> > Sent: 21. elokuuta 2001 23:31
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]; [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > Subject: Re: Higher level question about flow label
> >
> >
> > Jarno,
> >
> > The Carpenter/Conta proposal does include two formats for the
> > label (one aimed
> > at intserv flows and one aimed at diffserv flows), but if you
> > use the field
> > only for rapid routing lookup, you don't care about that; in
> > both cases you can treat
> > the label as 20 opaque bits I think.
> >
> > You only care which format it is when you are doing specific
> > intserv or diffserv
> > packet classification.
> >
> > Brian
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > Jim,
> > >
> > > Nice rant :-)
> > >
> > > Could you elaborate on the pseudo-random nature of the flow
> > label. It seems
> > > to me that if it did not need to be pseudo-random, people
> > could go on
> > > "signaling off-line" about the flow label values (in SLAs,
> > this seems to be
> > > what Alex & Brian want). I see no harm in allowing such
> > practice, but it
> > > would be best if there is only one format for the flow
> > label, as it would be
> > > faster to decode.
> > >
> > > Jarno
> > >
> > > > -----Original Message-----
> > > > From: ext Jim Bound [mailto:[EMAIL PROTECTED]]
> > > > Sent: 21. elokuuta 2001 15:58
> > > > To: Thomas Eklund
> > > > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob
> > Hinden; ipng
> > > > Subject: RE: Higher level question about flow label
> > > >
> > > >
> > > > thomas,
> > > >
> > > > that is why if we can treat the flowlabel as part of
> > tuple with src
> > > > address and identify a connection which identifies the
> > forwarding path
> > > > the challenge is reduced. there is nothing needed but the
> > > > header for the
> > > > look up and forward. I believe this can be made to work.
> > > >
> > > > the traffic class will provide diff serv metric and the flow
> > > > identifies
> > > > the E2E connection with the src addr.
> > > >
> > > > The src addr MUST be a global address.
> > > >
> > > > Site-Local can be done too but don't want to get into
> > that right now.
> > > >
> > > > One can ask if the Ipv6 address is global why have the
> > flow for per
> > > > connection as above. This is a good question and needs
> > discussion.
> > > >
> > > > First the flow assists with the lookup in a binary tree,
> > > > queue type, or
> > > > archaic hash. Its the hint to the next leaf, bucket, or
> > queue entry.
> > > > duplicat highorder bits would cause a branch. This could
> > speed up the
> > > > search before even getting to the global address.
> > > >
> > > > The src + flow could also be used as label for MPLS and its
> > > > in the IPv6
> > > > header.
> > > >
> > > > The business reason could also be that end users would
> > create SLAs for
> > > > their flow labels in addition the bits set for the traffic
> > > > class. This is
> > > > how QOS Int Serv could be realized. And I guess conjunct
> > > > with diff serv
> > > > but that would need to be specified too.
> > > >
> > > > This also benefits client and server boxes too (gateways
> > > > too). We can now
> > > > potentially keep one protocol control block for user
> > connections. tcp,
> > > > sctp, and dcp per connection data structures would not
> > have to be kept
> > > > above the internet per connection datastructures (e.g. bsd
> > > > inpcb would be
> > > > enough). This is a performance win for clients and servers
> > > > for IPv6 not
> > > > just routers or switches or gateways.
> > > >
> > > > If we put a length in the flow yes it can be made to work but
> > > > not without
> > > > being verified by the router as the packet is parsed or
> > > > "policed" then we
> > > > have just put new processing far worse than the IP
> > checksum which we
> > > > removed from the IPv6 router. And opens up opportunity for
> > > > bugs at that
> > > > code point we don't have today.
> > > >
> > > > I also don't support the field being mutable as it transits
> > > > the network
> > > > path to the end destination.
> > > >
> > > > The reason is that we should make IPv6 E2E perform in the
> > > > network as fas
> > > > as possible. If you look at all the work to do VPN, L2TP,
> > > > NAT, Virtual
> > > > Routing, et al that is emerging pervasive for IPv4 the root
> > > > reasons are
> > > > lack of IPv4 address space, the desire to do fast layer 2
> > > > switching, and
> > > > security inspection (e.g. firewalls).
> > > >
> > > > The later two above are the only valid visions. We need to
> > > > eliminate in
> > > > our thinking the mind set developed because of lack of IPv4
> > > > address space.
> > > > I could argue that what is happening to IPv4 is pure professional
> > > > irresponsibility on our part as Internet engineers. The
> > > > Internet should
> > > > remain E2E. This is not a politcal comment or even social
> > > > comment. Its a
> > > > comment stating my assumptions about how the Internet
> > should operate.
> > > >
> > > > I think we need to discuss our assumptions for the
> > > > requirements with the
> > > > solutions we define.
> > > >
> > > > ADSL box providers actually market that NAT helps you because
> > > > you don't
> > > > have to worry about address space. This is absurd and
> > professionally
> > > > irresponsible in the market. We should stop this with IPv6.
> > > >
> > > > The way to do that is give routers the means to forward
> > packets E2E by
> > > > only looking at the header of IPv6. That is what Brian's
> > "b" solution
> > > > does. Plus it benefits all nodes besides routes for IPv6
> > as I state
> > > > above.
> > > >
> > > > As far as IPv6 extensions. The payload length gives the
> > > > router the entire
> > > > length of the packet. If the flowlabel can be used to
> > > > identify forwarding
> > > > the packet in addition to the address and other parts as
> > I state above
> > > > then there is no challenge for ASIC vendors for strict
> > > > forwarding of IPv6
> > > > packets.
> > > >
> > > > If those vendors want to add more value by digging past the
> > > > header then
> > > > that is their option to add value but I don't believe it is
> > > > required for
> > > > fast forwarding of IPv6 packets.
> > > >
> > > > Steve's design works and I believe can be extended with the
> > > > flowlabell and
> > > > we can get rid of the mess IPv4 is making of the Internet
> > > > because of the
> > > > band-aids being applied.
> > > >
> > > > I believe the End System (and that could be a router in some
> > > > cases or a
> > > > broker router) should set the flowlabel at the access
> > exit before the
> > > > edge. But thats another discussion.
> > > >
> > > > Another discussion is how do we pick good random numbers for
> > > > the flowlabel
> > > > at the access exit end system or even a client.
> > > >
> > > > regards,
> > > > /jim
> > > >
> > > >
> > > > On Tue, 21 Aug 2001, Thomas Eklund wrote:
> > > >
> > > > > I agree alex.
> > > > >
> > > > > It gets worse for people that are doing ASIC which is not
> > > > programmable, then
> > > > > they need to spin a new version their ASIC when the
> > > > protocols changes. For
> > > > > people that are doing programmable ASIC (network processors
> > > > etc) this is not
> > > > > a problem.
> > > > >
> > > > > But common for both approaches is that the header format is
> > > > really challenge
> > > > > for the ASIC engineers
> > > > >
> > > > > -- thomas
> > > > >
> > > > > >-----Original Message-----
> > > > > >From: Alex Conta [mailto:[EMAIL PROTECTED]]
> > > > > >Sent: den 20 augusti 2001 22:15
> > > > > >To: Thomas Narten
> > > > > >Cc: Brian E Carpenter; Bob Hinden; ipng
> > > > > >Subject: Re: Higher level question about flow label
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >Thomas Narten wrote:
> > > > > >>
> > > > > >> [...] When someone can make a compelling argument for why
> > > > > >> the bits need to be defined in a certain way (i.e.,
> > > > there is a real
> > > > > >> application for which using the bits provides
> > > > significant benefits,
> > > > > >> and those benefits do not appear achievable through
> > > > other means) that
> > > > > >> is the time to define the bits. What I do sense with
> > many of the
> > > > > >> recent discussions surrounding the Flow Label is that
> > > > there are many
> > > > > >> folks (i.e., folks putting IPv6 into hardware) that want
> > > > to know what
> > > > > >> they should implement w.r.t. the Flow Label. While it would
> > > > > >be nice to
> > > > > >> be able tell them what to do, we shouldn't standardize
> > > > something just
> > > > > >> for the sake of having a definition.
> > > > > >>
> > > > > >> Thomas
> > > > > >
> > > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per
> > byte, or 3.2
> > > > > >instructions of a hypothetical
> > > > > >1Ghz processor which can execute one instruction per
> > > > cycle. That's a
> > > > > >hell of a requirement.
> > > > > >
> > > > > >As consumers, we all enjoy the very cost-effective
> > availability of
> > > > > >100Mb/sec line speed packet processing in almost every
> > > > > >Notebook, or PC.
> > > > > >
> > > > > >IP and QoS Engines implemented in silicon, on a chip or a
> > > > few chips, by
> > > > > >IBM, INTEL, and many, many others, is one of the
> > reasons of the low
> > > > > >costs, along with the ability to optimizing the hardware
> > > > > >in so many more and different ways than the software
> > (for instance
> > > > > >parallel header, or parallel header field processing).
> > > > > >
> > > > > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just
> > > > > >around the
> > > > > >corner, with 40Gb/sec following not long after.
> > > > > >
> > > > > >With such drastic "timing" requirements, implementing
> > engines in
> > > > > >silicon, and inventing *clever* mechanisms to handle
> > the sequential
> > > > > >processing of headers alone, will not be sufficient to
> > > > implement very
> > > > > >cost-effective IPv6 forwarding and QoS solutions, and
> > IPv6 is at a
> > > > > >disadvantage relative to IPv4.
> > > > > >
> > > > > >We need all the help we can get from the protocol, that is
> > > > headers, and
> > > > > >their fields, for forwarding and QoS processing, and by that I
> > > > > >mean both
> > > > > >Intserv, and Diffserv.
> > > > > >
> > > > > >Regards,
> > > > > >Alex
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
