Margaret,
The draft explicitly states that each transport connection SHOULD be labeled, and
explicitly mentions labeling enabling load-balancing that you described.
So I do not think there is any conflict with the intent of the authors (and the text)
and the uses you describe.
The intent of the "SHOULD NOT" you refer is not to conflict with the other text in the
draft. I still think it would be dangerous if IPv6 nodes create *flow-specific* state
based on a random packet they forward. Load-balancing applications does not need state
per-flow, but state per interface. This state is created before any packets are
forwarded, or the state can be algorithmically deduced from the packet headers. This
is explicitly included in the definition of the "flow state establishment method" in
section 1. No new state entries are created when packets are forwarded (esp. memory
usage is not increased after load-balancing an outgoing packet).
Another way to put it is that load-balancing works on aggregates of flows where by
some function (e.g. a hash) packets from a single flow are deterministically mapped to
the same outgoing interface (unless routing changes).
The defined flow labeling policy guarantees that different flows do not use the same
flow label with the same addresses at the same time. Currently the text states that it
is the responsibility of the "flow owner" to hold on to the label as long as required
for any flow-specific state to be cleared from the network. In case of load-balancing
there is no flow specific state to be cleared.
Even if load-balancing would not require consecutive flows to have different labels, I
agree that it would be useful not to re-use a recently used value for some time unless
otherwise requested by the "flow owner". However, I really would not like to specify
any minimum timeouts nor define a single mandatory method by which this must be
accomplished.
Would it be adequate to state that "The facility SHOULD NOT assign a previously used
value sooner than it needs to. This can be accomplished for example by monotonically
increasing the assigned value for each new flow."? (The random initial value is
already in the text). This would leave ample space for implementation specific methods
for e.g. partitioning the flow label space, assigning randomly selected values
(statistically different from any recent value), etc.
Technically, the above addition is not needed, since the draft already states that a
value may not be reused until all flow-specific state has been cleared from the
network. After the state is gone, no-one will know the value is re-used... Anyway, it
would provide useful guidance for implementers.
Jarno
> -----Original Message-----
> From: ext Margaret Wasserman [mailto:[EMAIL PROTECTED]]
> Sent: 1. elokuuta 2002 22:30
> To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; Hinden Bob (IPRG)
> Subject: Re: Flow label draft issues & new text
>
>
>
> Hi Jarno,
>
> >The method by which the flow state is cleared from the IPv6
> nodes is to be defined by the flow state establishment method
> used to set up the state. This implies that IPv6 nodes SHOULD
> NOT establish any flow-specific state unless so instructed by
> a specific flow state establishment method.
>
> I don't agree with the "SHOULD NOT" above...
>
> There are some potential uses for flow identification that do
> not rely on
> any sort of flow establishment mechanism or signalling, such
> as the use of
> flow labels for load balancing.
>
> To have a useful flow label for these mechanisms, an IPv6
> node simply labels
> all of the packets in a given TCP/SCTP connection or UDP
> communication with
> the same flow label,making some basic effort not to re-use
> flows too often --
> such as starting with a random number and monotonically
> increasing it for
> each new connection or communication.
>
> It would be fairly trivial to assign a flow label in this
> fashion -- not
> much harder than setting it to zero. So, you get a
> reasonable return for
> very little work.
>
> Of course, this type of non-unique flow labeling isn't
> consistent with using
> flow labels to cache next-hop information, for example. For
> those more
> sophisticated needs, a real flow establishment (and
> maintenance) method may
> be needed. But, I don't think that we should require a more
> sophisticated
> method to be present in order to use the flow label at all.
>
> 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]
--------------------------------------------------------------------
