Margaret Wasserman writes:
>
> >
> >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).
I guess I don't understand why that's a bad thing.
Routers currently classify flows with transport headers,
etc, but that's because it's the only thing they _can_
classify with. The flow label pushes classification
back to the host which, IMO, is where it really
belongs since it's the only that that _really_
knows what constitutes a "flow".
> > > 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?
[much elided]
> 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?
Er, well, it _doesn't_. I guess I just don't
attach any special meaning to the word "flow";
that is, a flow is whatever the host says is a
flow. If it's bizarre, then well, why should
the router care? Again, other than maybe gaming
fair queuing algorithms[*], why do routers
actually care about what constitutes the
sematics of the flow? It's really in the host's
best interest to be network friendly, right? To
give routers information which increases the
probability of forwarding its packets in the
manner it hopes for, right?
> 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?
Well assumedly the server farm wouldn't all
have the same IP address, so they'd be different
flows.
> - The flow label contains a packet classifier.
Er, but the flow label *is* an element of a
packet classifier, or rather perhaps a
replacement for the current method of classifying
packets. I thought as far as routers are
concerned, flow label were opaque and that no
internal semantics were visible.
> 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?
This seems to me to be a self-healing problem:
if it screws up load balancers by using strange
definitions of flow, hosts are probably what
will notice via reduced throughput and... stop
doing that ("Doc it hurts when I hit myself in
the head..."). Though I must say that I still
don't see that it would hurt them.
> 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.
I'm still completely lost. How does it make it
useless?
Mike
[*] this could conceivably be mitigated by first
classifying by IP address and then draw down
each different flow from its own token bucket,
thus a host would only be screwing itself.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
