Derek Fawcus wrote:
>
> > 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.
>
There is specific proposal on the table
<http://search.ietf.org/internet-drafts/draft-conta-ipv6-flow-label-02.txt>,
that proposes changing the current IPv6 flow label specification to add a
non-pseudo-random-number format in addition to the existing format. In my
message I noted that if this is done, implementations (HW or SW) will need
to be able to look up on the basis of both formats, which led me to think
that a single format fulfilling all the requirements might be better.
Also, as currently defined, most packets are sent out with flow label value
0x00000, which makes it particularly bad field for a generic route
distribution hash.
Now, if some portion of the non-zero flow label values are going to be
non-random, what is the value of having the rest of them to be
pseudo-random, especially if it is unknown what the distribution between the
random and non-random formats is?
If the pseudo-random nature of the current flow label specification is very
important and cannot be changed because of router (HW) implementation issues
(of which I do not really know much), then the proposal in the draft cannot
be supported at all. On the other hand, if the pseudo-random number nature
of the flow label is not that important, why keep it?
If it is deemed that the flow label shall support the route distribution for
load balancing then each flow should be assigned a flow label value
independent of the flow QoS requirement (i.e. the default flow label value
should not be used at all). Even then the pseudo-random number requirement
seems too strong, as usage of a simple incremental value (+1 for each new
flow) would seem to result in balanced distribution as well.
Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
