Subject: Re: Higher level question about flow label

From: "Kastenholz, Frank" <[email-masked]>
Date: Fri, 24 Aug 2001 13:27:53 -0400

All this talk about the format of the flow-id field
is rather interesting. But one thing has been missing -- 
input from someone who will actually _look_ at the
field, at very very very high speeds, in hardware,
and make forwarding decisions based on it.

I am fairly confident in saying that there will not
be many sqmm of silicon devoted to determining
if the flow id is 'intserv-format' or 'diff-serv
format' or 'tennis-serv format'. The edit/compile
/debug loop of silicon is such that we can not 
react soon enough to the next format that is
developed. This means that the flowid looker-
upper will be very very general. That means
that we don't care what the format is. We just
take the whole 20-bits and look 'em up (e.g.,
throw them all at a CAM, and see what comes out)

The only thing that would make the looker-upper's
job easier is to know that the flow-id is going
going to be shorter than 20 bits (maybe via the
protocol specification, maybe via some software
magic ala MPLS label negotiations). A looker-upper
that is limited to 4 bits is a different beast
than a looker-upper that does 20. 

So, you folks can argue all you want about the format
of the flow-id and those format differences may matter
at some level in the software. But to the people who
are the actual customers of the bits -- the silicon
forwarders -- it just doesn't matter. 

Frank Kastenholz

--------------------------------------------------------------------
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 17:10:50 -0500

Frank,

Not all network processors have the degree of inertia
you describe. I know of at least one that can adapt to
format changes without new silicon.  But that aside,
what I am talking about is multi-field classifiers in
border routers, not what happens in core/trunk routers
where you are completely correct - that is why the diffserv
code point is 6 bits (sorry, we couldn't squeeze to 4).
Multi-field classifiers don't need to be "slow path" but
they aren't subject to quite the constraints you mention,
in the diffserv architecture. 

This is the essence of why diffserv scales and intserv
doesn't- you only need to do multi-field classification
at the borders. Actually the format we are proposing
simplifies MF classifiers because it takes away the need
to look at port and protocol numbers.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2001 11:25:53 -0500

Understood. This is all fine as long as the ASIC or network
processor can use a common solution for per-flow and
per-traffic-class classification - in that case it doesn't
care what the bits in the flow label are (although the
software that configures the tables that drive the classifier
might care).

  Brian

"Kastenholz, Frank" wrote:
> 
> Brian
> 
> You're missing my point.
> 
> Yes, there are some silicon forwarders that can be
> easily adapted to changes in the header fields --
> assuming that those changes are within the range of
> flexibility that was already placed in the silicon.
> ASICs are less flexibile than FPGAs which are less
> flexible than NP's. But all that is more or less
> irrelevant.
> 
> The issue is the "format" of the flowid. I'd code things
> up to classify on the full 20 bits of the flowid and
> be done with it. That way, I will not have to go back
> into the forwarder design, _regardless_ of the
> environment. Any time we have to change code, it's
> a bad thing -- bugs can creep in, unintended behaviors
> can result, performance can suffer. Even if the silicon
> is flexible, it has some "programming" and that programming
> would have to change if I made it too aware of the internal
> details of the field.
> 
> Frank Kastenholz
> 
> At 05:10 PM 8/24/01 -0500, Brian E Carpenter wrote:
> >Frank,
> >

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Tue, 28 Aug 2001 10:12:26 -0400

Brian

You're missing my point.

Frank Kastenholz