On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
> I think the WG needs to decide once and for all whether the flow label is
> a) a CATNIP or MPLS-like routing handle
> or b) a QOS hint for intserv only
> or c) a QOS hint for intserv and diffserv
> or d) a waste of bits
>
> We can get back to the details once we have a consensus on this.
I'd suggest e) A flow identifier for router optimisation.
I sort of see this as a variation of b), i.e. it identifies a flow using
a PRN but does not imply any QoS usage. However it doesn't preclude the
flow label being used in scenario b).
Specifically - I see it as a way of replacing the srcPort/dstPort tuple
that routers peek at in the TCP/UDP header. Currently I only see this
being used in one scenario, that is for load balancing across multiple
paths.
At the moment (for v4) if a lookup on the dst address address leads to
a route with multiple paths, and the route is appropriatly marked,
the flows of packets can be shared across these multiple paths. This
is done (for min size IPv4 headers, carrying TCP or UDP) by hashing
the srcIP/dstIP/srcPort/dstPort and using this to help choose which
path to forward the packet over.
Given that for IPv6 we can't guarentee the TCP/UDP header is at any
given offset, or even that it's readable. One would need some other
way of identifying flows if the above load balancing was to be performed.
For v6 a core router engine (either s/w path, or ASIC [as fix logic
or programable device as someone suggested]) one will not be looking
beyond the base IPv6 header. For an edge rouer engine, one may well
be looking inside the packet for say classification.
Hence use the flowID. Without this we could only hash based upon the
srcIP/dstIP and hence all flows between a given src/dst pair will hit
the same path.
With this info in the flow label, one would be able to hash together
the srcIP/flowLabel to find the correct path. As a router in this
situation one would always have to combine the src IP address, but
if the flow label was defined to uniquely distinguish a given
dstIP/srcPort/dstPort flow, one could skip compining the dstIP at
the router.
The reason for specifying that it be a PRN is simply to make the hashing
cheaper at the router.
I said above that this doesn't preclude using the flow label for scenario
b), this can be achieved simply by picking a PRN for scenario b) from
the same number pool as for scenario e). Thus if intserv QoS is being
used, a (set of) routers would have been informed (via RSVP)
about the relationship between that flow label and certain QoS
requirements, any other routers in the path of the packet flow that
don't know about intserv/RSVP will simply treat packets in the flow as
scenario e).
So the usage becomes one that is (potentially) orthogonal to QoS. It
will be usable for non QoS'ed (intserv or diffserv) packets, as well
as with both intserv and diffserv.
On Wed, Aug 22, 2001 at 11:41:30AM +0300, [EMAIL PROTECTED] wrote:
> 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?)]
I'd disagree. The router should only use the RPN in a situation where a DoS
can't occur.
Take my example above - the route has already been looked up (using the
dst IP address), and we've got multiple paths. We're now going to use
the flow label to help pick the path.
So say a set of originating hosts pick a poor PRN, all that happens is
that they end up getting less available bandwith for all of their flows.
This on the assumption that their choice of a poor PRN causes a sub set
of the available paths to be picked.
Note however that this doesn't affect other hosts with a good PRNG which
will be able to use more/all of the available paths. It also doesn't
mean that a DoS on any given path will occur - since queuing (say WRED)
will occur after having picked a path.
The only party hurt by their choice of a poor PRN is themselves.
> 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.
Lookups only occur when a QoS type funtion is applied to the flow label,
say we've been told about a flow by RSVP. In this case a PRN still helps
since we can reduce the cost of lookups by hashing on the flow label to
pick a subset of flows before doing a search/comparison.
But then if the flow lable was a PRN, we'd simply skip the hash and use
some of it's bits as a hash bucket index, before jumping to the search
and comparision phase.
If QoS is not in use for that particular route & flow label, then if the
value was not random, we'd have to use a more complex hash algorithm in
order to make sure we had got a good bucket distribution.
DF
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
