Subject: RE: Higher level question about flow label

From: [email-masked]
Date: Wed, 22 Aug 2001 23:41:31 +0300

Brian,

Current (intserv) usage requires signaling to convey the semantics for the
opaque flow label values. The diffserv usage would allow the flow label
itself to function as a pointer to the semantics (taken out of configuration
file or equivalent). In both cases the classifier will most likely do same
kind of a search on the flow label, but the population of the data found for
the matching entry is different (configuration vs. signaling).

Also, an source knowing about well known values would know not to use those
values for opaque ones. Additionally, it might not be harmful even if it
would be possible to signal a specific (overloaded) semantics for a "well
known" flow label (for a specific source).

I'm assuming here that the only difference between the two cases being
discussed (from the classification point-of-view) is that for the intserv
case the same flow label value would carry the same semantics for all
possible sources, while the semantics for the opaque values are specific to
the source IP address.

	Jarno

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 22. elokuuta 2001 22:54
> To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: Higher level question about flow label
> 
> 
> 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-masked] 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-masked]]
> > > Sent: 21. elokuuta 2001 23:31
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]; 
> [email-masked];
> > > [email-masked]; [email-masked];
> > > [email-masked]
> > > 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-masked] 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-masked]]
> > > > > 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-masked]]
> > > > > > >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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Aug 2001 11:42:06 -0500

My understanding is different. I thought that diffserv classifiers would
learn and cache the flow ID from the first packet of an intserv flow, such
that for subsequent packets they can classify simply on the 2uple
{source address, flow label}.

You don't seem to accept that there is a fundamental difference between intserv
classifiers (which are specific to microflows) and diffserv classifiers (which
are specific to traffic classes and blind to microflows). This is why there have
to be two formats if we want to support both intserv and diffserv with the
flow label.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------