Thomas,
See my comments inline:
> > > > We don't know, and 60 seconds is a compromise value anyway.
> > > But there
> > > > seemed to be WG consensus that a default timeout is
> needed, since
> > > > otherwise we are licensing implementors to create hard
> > > state. The authors
> > > > have been round and round this many times, and this was
> the best we
> > > > could come up with. (more comment on this below)
> > >
> > > Well, I have a basic problem with a default timeout of 60
> > > seconds. Heck, a temporary routing glitch can cause a
> loss of traffic
> > > for 60 seconds, yet the TCP sesssion doesn't go away that
> quickly. So
> > > 60 seconds seem like a rather odd compromise value. Seems
> too short to
> > > me.
> > >
>
> > Presumably the node can re-create the state it needs after the
> > gap. Since there was a long gap, there should be no reordering
> > issues (in case the new state for example determines a different
> > next-hop interface).
>
> > For reference, RFC 1883 defined a lifetime value of 6 seconds.
>
> Not really relevant, as that had to do with the now discredited
> opportunistic caching that is explicitely deprecated by this document.
>
Well, IMO the default lifetime has no other function than enabling opportunistic
caching (if everything is based on a explicit set-up, the lifetime for each flow can
be set up individually, and no default is needed). As a consequence of adding the
default lifetime, I removed the "SHOULD NOT" that prohibited setting up state without
a set-up mechanism.
> > As I said above, I do not know any use of flow-specific state
> > without the support of a flow state establishment method. But if we
> > do not define a default lifetime now, it cannot be added
> > later. Also, it seems logical to have *some* pause before a
> > previously used flow label value should be re-used for a new flow.
>
> I don't necessarily disagree with the need for a default lifetime. But
> I think 60 seconds is too short. It seems to me that it would be
> better to tie it to something more meaningful, like TCP lifetimes. At
> least, if we're just picking a value out of the hat. Why is 60 seconds
> better than 2 minutes? Why is 2 minutes wrong compared to 1 minute?
>
> Let me state it differently. What I'm hearing is that we want a
> default, but that 60 seconds has been pulled out of thin air. I can't
> evaluate whether that is a good default or not, because I don't
> understand the tradeoffs. I'm arguing that its too short, but the
> reasons for keeping it short don't seem (to me) to be very
> rigorous. What are the tradeoffs here that would lead one to pick a
> longer or shorter value? Some thoughts:
>
> There is a cost associated with a short default, in that routers will
> be forced to rebuild the flow state more frequently. Given that
> temoporary routing issues can easily last more than a 60 seconds, and
> that a normal TCP connection/flow will sometimes not send traffic for
> 60 seconds, I worry that this cost is relatively high. Is that cost
> justified?
>
> There is also a cost for the default being longer on hosts, as they
> need to not reuse flow labels too quickly. The issue seems most acute
> across reboots. Is it substantially more overhead for a host to not
> reuse a flow label for (say 5 minute) vs. one minute? I don't think
> so.
>
> Are there other issues that should be considered here?
>
If e.g. random initial value and sequential allocation is acceptable after reboot,
then there is no additional cost to the host on even longer than a few minute timeouts.
But a short default timeout should not be a burden on routers either. There are two
cases:
1) opportunistic set-up: the overhead of setting up the state must be negligibly
small, as the router needs to be prepared to set up state for each incoming packet (in
the worst case scenario). If so, the difference between 1 and 2 minute default
lifetime should be of no consequence
2) Flow set-up with a flow set-up mechanism: The mechanism can set whatever lifetime
it wants. If the mechanism is concerned by TCP timeouts, then the minimum lifetime
being set up with that mechanism is likely to be 2 minutes (?). Some other mechanisms
could utilize lifetimes considerably longer (e.g. 1 hour), depending on the cost of
setting up and maintaining the state with that mechanism.
My take is that for 2) the default lifetime value has no real meaning (other than
hosts need to keep the labels in quarantine for the default duration, even if the flow
set-up resulted in a shorter lifetime, because there could be a node in the path not
taking part in the mechanism, but opportunistically caching the flow).
For 1) even 6 seconds should be fine.
> > WG chairs (collectively) insisted on the definition of the default
> > lifetime, and there were no opposing voices on this from the WG.
>
> > I do not think the default lifetime should have anything to do with
> > TCP timeouts, as long as it is long enough to not cause any
> > reordering issues. But this is not an issue for me, any value is
> > fine, especially if someone could come up with good justification
> > for the value :-)
>
> The comment about reordering suggests some reason for a particular
> value. But I don't understand what the reording issue is. In general,
> we don't want to reorder packets. Not good for TCP. But reording can
> happen, and it doesn't break things if it's a transient issue. What
> reordering issues occur with flow state? If I understood the issue
> better, it might lead me to agree that 60 seconds makes sense. But I
> don't have a good handle on the underlying issue.
What I referred to as reordering issue is that if some node is making a forwarding
decision based on the flow identity (some form of load balancing), the packets of the
flow should remain in the same path. But if there is a gap of couple of seconds
between the packets, there would be no re-ordering even if the path for packets after
the gap is different. This assuming that packets will not stay in the network for many
seconds.
>
> Thoughts?
>
According to what I have presented above, minimum default lifetime we can consider is
"a couple of seconds". There is no hard upper limit. To keep grounded on something I
understand, I have proposed shorter rather than longer timeouts. But I'm open to any
suggestions.
Would everyone be happy with 2 minutes?
> > > > > What problem is the above wording intended to address?
> > >
> > > > Use cases that nobody has thought of yet.
> > >
> > > I don't understand this answer. If a router does something
> > > flow-specfic for flow X, but then sees no traffic for 60
> seconds, the
> > > implication now is that it shouldn't give flow X the same
> treatement
> > > it was just giving it just 60 seconds ago.
> > >
>
> > No. It would still give the flow X, but it would just need to re-use
>
> s/would/could/? If it will continue giving the flow X, what was the
> point of re-creating X?
>
> > the algorithm/method/whatever to re-create the X after the gap, if
> > it flushed the X.
>
> > It might be likely that X is not really flow-specific, but can be
> > applied to aggregates of flows. In this case there is no point in
> > flushing the X (ever).
>
> > > > > > 3. Flow Labeling Requirements
> > > > > >
> > > > > > To enable Flow Label based classification, sources
> > > SHOULD assign each
> > > > > > unrelated transport connection and application data
> > > stream to a new
> > > > > > flow. The source MAY also take part in flow state
> > > establishment
> > > > > > methods that result in assigning certain packets to
> > > specific flows. A
> > > > > > source which does not assign traffic to flows MUST
> > > set the Flow Label
> > > > > > to zero.
> > > > >
>
> > You left the 2nd paragraph out from your quote. I think it should be
> > considered here as well:
>
> > "To enable applications and transport protocols to define
> what packets
> > constitute a flow, the source node MUST provide means for the
> > applications and transport protocols to specify the Flow
> Label values
> > to be used with their flows. The source node SHOULD be
> able to select
> > unused Flow Label values for flows not requesting a
> specific value to
> > be used."
>
> OK. I still find the wording a bit confusing though. Maybe it's
> because of the use of the term "source". Source can mean application,
> or the IP stack or the host as a whole. Above, I guess it means "IP
> stack", but I have to think about this before coming to that
> conclusion. It might be better to be even more precise.
>
Further comment on this?
> > > Note: this last sentence seems hard to achieve. it
> suggests that if a
> > > future flow establishment method uses longer lifetimes,
> the stack will
> > > have to be retrofitted to figure out somehow not to reuse
> those flow
> > > label values for the longer period. I suspect that future
> uses of the
> > > flow label (i.e., the signalling partz) may well be implemented
> > > separately from the base IP stack Flow Label support, and
> it may not
> > > be possible for the signalling to ensure the quarantine behavior.
> > >
>
> > There are at least two ways to implement this:
>
> > 1) the stack implementation allows the application (or any
> > middleware on top of the stack) to define the lifetime, that the
> > stack will then honor (e.g. by not assigning that value to any new
> > flow for the timeout value after all sockets belonging to that flow
> > have been closed), possibly individually for the flow, or by
> > utilizing the longest timeout for all flows.
>
> > 2) In the absence of the interface for the non-default lifetime, the
> > FSEM could keep the flow "reserved" for timeout-60 seconds after the
> > flow's traffic has finished, and only after that release the label
> > back to the stack (which would then keep the value reserved for the
> > normal 60 seconds).
>
> I agree the above can be done. Do you really expect implementations to
> do 1) above based on the wording in the current spec? I have my
> doubts.
>
Suggestions on this?
> > How about:
>
> > "The requirement of not reusing a Flow Label value for a
> new flow with
> > the same pair of source and destination addresses extends across
> > source node crashes and reboots. To avoid accidental Flow
> Label value
> > reuse, the source node SHOULD select new Flow Label values
> in a well-
> > defined sequence (e.g. sequential or pseudo-random) and use a
> > different initial value for the sequence each time the
> system starts.
> > The initial value could be randomly generated, or computed from a
> > previous value stored in non-volatile memory."
>
> Better, but still not quite right. If the machine has no stable
> storage for remembering previous values, the random approach is the
> best we can do. But for those with stable storage, random is
> presumbaly less desirable, and the new value should be based on
> previous history. If that is what we want to recommend, it would be
> better to just say so. It is also not enough that it uses a
> "different" initial value from the previous initial value, it needs to
> be one that avoids collisions with recently previously used flow
> IDs. E.g., something like:
>
> To avoid accidental Flow Label value reuse, the source node SHOULD
> select new Flow Label values in a well-defined sequence
> (e.g. sequential or pseudo-random) and use an initial value that
> avoids reuse of recently used Flow Label values each time the
> system restarts. The initial value should be derived from a
> previous value stored in non-volatile memory, or in the absence of
> such history, a randomly generated initial value using techniques
> that produce good randomness properties [RFC 1750???].
>
Agree. Will check if the reference is right.
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]
--------------------------------------------------------------------
