[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: I-D ACTION:draft-ietf-ipv6-flow-label-04.txt
From:       Thomas Narten <narten () us ! ibm ! com>
Date:       2003-01-20 16:34:07
[Download RAW message or body]

> So how about this:

> "The 20-bit Flow Label field in the IPv6 header [IPv6] is used by a
>  source to label packets of a flow. Packet classifiers use the triplet
>  of Flow Label, Source Address, and Destination Address fields to
>  identify which flow a particular packet belongs to. Packets are
>  processed in a flow-specific manner by the nodes that have been set
>  up with flow-specific state. A Flow Label of zero indicates an
>  unlabelled packet that is given no special treatment. The nature of
>  the specific treatment and the methods for the flow state
>  establishment are out of scope for this specification."

Works for me.

> > > Well, I think we want the SHOULD in there. We mean it.
> > 
> > Make the "SHOULD implement" a separate point from the definition
> > itself then. And have it refer specifically (for hosts) that they
> > SHOULD label outgoing packets. That is what I think we are aiming for.
> > 

> I think we are stating the "SHOULD label" in the section 3 ("Flow
> Labeling Requirements") is sufficient? Comments?

Agreed.

> > > 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.

> 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?

> 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.

Thoughts?

> > > > 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.

> > Here's a slightly less delta-ish proposal relative to the current
> > text:
> > 
> >    A source node MUST ensure that it does not reuse Flow Label values
> >    it is currently using or has recently used when creating new
> >    flows. Flow Label values previously used with a specific pair of
> >    source and destination addresses MUST NOT be assigned to new flows
> >    with the same address pair within 60 seconds of the termination of
> >    the previous flow. If the previous flow had a lifetime longer than
> >    the default 60 seconds, a quarantine period of at least the length
> >    of the lifetime MUST be observed before reusing that Flow Label.
> > 

> The changes (1st and last sentences) seem good to me.

OK.

> > 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.

> 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???].


> You might want to read the -03 draft (at
> http://www.ietf.org/proceedings/02nov/I-D/draft-ietf-ipv6-flow-label-03.txt
> ) it had 6 requirements. Some of them were clarifying implications
> of the other text, but were cut of to reduce the complexity of the
> document.

> It would be good if you could read the -03 version to see if we
> dropped something that really should not have been dropped (as you
> see it).

I don't see anything critical that was dropped.

> If the proxy is aggregating traffic so as to share a flow, then it
> no longer "my bandwidth" or "your bandwidth", it is just aggregate
> bandwidth that the proxy is responsible for managing, at least
> responsible for which traffic it is inserting to the aggregate. From
> the IPv6 viewpoint the proxy is the source of the flow.

OK

Thomas
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]