>
>Maybe I'm in left field here, but I thought that a
>transmitter who didn't mark packets' flow label
>was supposed to set it to zero. In that case, the
>router could conceivably resort to classifying packets
>the old fashioned way -- eg transport headers.
The problem is that the current specification allows information other
than a flow label, such as a packet classifier to be placed in the
flow label field. So, a router cannot know that a non-zero value labels
a flow (i.e. one direction of a TCP connection).
> > It would be very bad, though, if the flow label were used, for example,
> > to tag packets that contain a TCP SYN, or packets that contain IP options,
> > or all HTTP packets, or packets that want a certain class of services,
> etc.
>
>Er, why would this be bad?
There are a couple of ways in which you would like to be able to use
the flow label field to simplify load balancing.
One is a router with support for multi-path routing. There is more than
one path out of this box that will reach the same destination, perhaps
with some sort of weighting value to indicate what portion of the traffic
should be sent over each path.
Today, these routers need to do packet classification on the IP addresses
and the upper-layer port numbers if they want to avoid sending data from
the same connection over different paths, which can result in packet
reordering, etc.
If the flow label actually labeled a flow, these routers could use the
IP addresses and the flow label to keep packets from the same flow together,
instead of having to parse the variable-length IP headers to find the
upper-layer port numbers.
Another application is a load-spreading router that spreads incoming TCP
connections across a group of servers. This box sets up state for each
incoming connection, and needs to ensure that all packets for the same
connection are sent to the same server -- otherwise the connection will
be reset.
It would be useful if these boxes could set-up state based on the IP
address and the flow label, instead of having to parse headers down to
the TCP header to find the port numbers.
Both of these mechanisms rely on the flow label labeling one direction of
an upper-layer connection (the definition I usually associate with the
word "flow").
If some nodes set their flow label to zero (indicating that they don't
participate in flow labeling), these mechanisms will still work. The
lookup for those packets will be less efficient, but it would still work.
What doesn't work is if there may be non-zero values in the flow label
that actually don't label flows. How is a load-balancing or load-spreading
router supposed to know that this isn't a flow label?
I gave two examples which Brian Carpenter said he specifically had in
mind for possible uses of the flow label:
- All HTTP packets get the same flow label.
How would this work with a load spreader that is
trying to spread connections between a group
of web servers?
- The flow label contains a packet classifier.
This *might* be okay, if values aren't reused too
often, and if a single connection always uses
the same value.
But, Brian specifically stated that he wants finer-grained control over
flow label values than a per-connection value. How would that work with
load-spreaders?
If the WG really wants to define the flow label so that it can be used
for signalling-based mechanisms like RSVP, NSIS and diffserv, with the
clear understanding that this makes the value _USELESS_ for the types
of applications I've described above, that is fine with me.
But, it isn't true that the defined mechanism lets us do both.
Margaret
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
