Subject: Flow label draft issues & new text

From: [email-masked]
Date: Thu, 1 Aug 2002 16:09:44 +0300

I have gone through all the flow label related issues raised on the list during the last month. In my opinion there were no big issues, but some clarifications in the text were necessary. I have included a new revision of the text, with the summary of the changes below.

I'd like you to raise any objections you may have against the changes ASAP, so that we can get the document finished.

	Jarno

 <<draft-ietf-ipv6-flow-label-xx.txt>> 

Summary of changes since -02:

Abstract:

- Added a paragraph to the Abstract to shortly motivate the Flow Label usage

1. Terminology and Definitions:

- Changed the definition of "Classifier" to the definition of a "Flow classifier"
- Flow: Deleted "(s)" from "destination(s)", as a multicast destination does not need the plural form. This change applied elsewhere as well.
- Flow state: added "More than one flow can map to the same flow state." to clarify the relation between a flow and flow state.
- Flow state establishment method: Changed "source" to "source or destination"

4. Flow Labeling Requirements:

- Added "in the order of precedence" before the numbered list of ways of labeling flows to clarify that e.g. (1) (if implemented and applicable!) takes precedence over (4), even though (1) is a MAY and (4) is a SHOULD.

- Added "If multiple flow classifiers map to the same flow state it may be desirable to minimize the amount of state and use the same Flow Label value with all such classifiers."
  -  to clarify the text about using the same Flow Label value for multiple address pairs.

- Changed language from "verifying" and "new" to "selecting" and "unique" in relation to the 'facility' to be more precise.

- Changed from:

"When a dynamically instantiated flow terminates, its Flow Label value MUST NOT be reused until it is certain that all associated state has been deleted from all nodes on the path. With some flow state establishment methods signaling new state may be sufficient. A mechanism with a sufficiently long timeout period before reusing the Flow Label values can also be used."

  to:

"Any Flow Label value not currently assigned by the facility can be assigned by the facility at any time. Accidental Flow Label value reuse SHOULD be prevented by not deleting the flow from the facility before it is certain that all associated flow specific state has been deleted from all relevant nodes. Collisions due to accidental node reboots SHOULD be minimized by utilizing a random initial value for the Flow Label being assigned by the facility.

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. With some flow state establishment methods, signaling new state simultaneously clearing the old state from the new path may be sufficient. A mechanism with a sufficiently long timeout period before reusing the Flow Label values can also be used."

This should settle the discussion on the list about flow label value reuse, timeouts, etc.

5. Flow State Establishment Requirements:

- Changed from: 

"(e.g. SCTP flows with multiple addresses at either end-points, or a diffserv classifier with an address range. See ..."

  to:

"(e.g. an SCTP connection between nodes with multiple addresses, or a classifier with an address range, see ..."

  to clarify the text.

- Removed the requirement (6). This was due to feedback from the NSIS WG, and due to the realization that exact method by which a migrating flow is identified is immaterial to the flow label spec itself. Any form of a globally unique "session id" could be used, and it does not need to be related to IP addresses. Furthermore, it is up to the flow state establishment methods to define if they support flow migration or not.

Security Considerations:

- Removed the first paragraph. The argument against it was that the flow label field does not add any new vulnerability, compared to the case without the flow label field usage. Finer granularity analysis can already be performed based on the other protocols fields.

Informative References:

- Removed the reference to the personal draft

---

From: [email-masked]
Date: Fri, 2 Aug 2002 14:40:06 +0300

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-masked]]
> Sent: 1. elokuuta 2002 22:30
> To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; 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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 2 Aug 2002 14:44:05 +0300

Itojun,

Let's agree first what the "SHOULD NOT" applies to, see my response to Margaret. Anyway, we have explicitly tried to encourage KAME-style flow labeling as the default by the IPv6 stacks. But obviously there still are some details to get cleared up to avoid ambiguous interpretation of the text.

	Jarno

> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 2. elokuuta 2002 6:08
> To: Margaret Wasserman
> Cc: Rajahalme Jarno (NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]; [email-masked]; Hinden Bob
> (IPRG)
> >There are some potential uses for flow identification that 
> do not rely on
> 	I agree with Margaret.  KAME has been doing this (automatically
> 	assign flow labels to TCP/connected UDP traffic) for a 
> long time,
> 	so that we can help traffic analysis/diffserv researchers.
> 	(they can't correlate traffic due to the use of ESP, or SSH)
> 	draft-itojun-ipv6-flowlabel-api-01.txt has more details on it.
> 
> itojun
>