Subject: RFC3697bis draft, and rationale, and open issues

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Jan 2011 16:36:49 +1300

Hi,

As requested by the 6MAN chairs, we have posted a draft update
of RFC 3697:

http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-3697bis-00.txt

At the same time we have posted
http://www.ietf.org/internet-drafts/draft-ietf-6man-flow-update-02.txt
which is now a rationale document for the changes to RFC 3697.

Our intention was to make only the changes to 3697 that are
directly implied by the discussions on the previous -flow-update
drafts**. However, while preparing the draft of 3697bis, we came up
with quite a few open issues. The attached document lists them.
If you'd like to comment on them, *please* set a subject that indicates
which issue you are addressing.

** and we've included a trivial fix for an old problem with RFC 2205.

Regards
   Brian + co-authors

---

From: Jarno Rajahalme <[email-masked]>
Date: Mon, 31 Jan 2011 14:30:19 +0200

Brian,

Here is my take on the issues 1 & 2:

> Open issues in 3697bis
> 
> --------------
> ISSUE 1. A basic assumption in RFC 3697 is that flow labelling mechanisms will
> be stateful and may need signaling. The changes discussed in the WG clearly
> address a stateless approach that needs no signaling.
> 
> QUESTION: do we keep the text about flow establishment methods, or do we simply
> remove it as being redundant? (This affects quite a lot of text in the draft,
> and there will be several secondary issues to discuss if we keep this text.)
> 

These are two different things: flow labeling (which labels to assign) and flow state establishment (how to treat specific flows). My own reading has been that flow labeling mechanisms may be stateful or stateless (for example, pseudo-random sequences were mentioned explicitly), and that signaling mechanisms may be needed to provide flow-specific treatment.

If the changes lead to a situation where it is common that labels set by the source are inconsistently changed in transit, it may be futile to even try classifying based on such ephemeral labels. In this regard the bis text is ambiguous. In one hand it says that the label, once set to a non-zero value, MUST be delivered unchanged to the destination(s), but elsewhere is says that domains MUST NOT export any other label values than zero or "pseudo-random". IMO the only practical way to ensure pseudo-randomness on domain exit is to overwrite the value with a new pseudo-random value, hence the contradiction.

One possible way forward in this regard is to mandate that any domain-exit rewrite be consistent, in practice mapping the received non-zero value for a flow to a consistent new pseudo-random value. The rationale for the mapping is to get from a possibly skewed short time-scale distribution (1,2,3,...) to an approximately even pseudo-random distribution, also over short time-scales. This should be easily doable with a router-specific key and pseudo random generator that takes the previous flow label value as an input (in addition to the source and destination addresses), always producing the same output for the same set of input parameters and key.

Also, I'd keep the possibility for flow state establishment methods, but drop the text relating to an API by which applications can set the flow label value, as this is in direct conflict with the new pseudo-random requirement. This includes dropping all text relating to any quarantine periods, as the pseudo-random requirement already provides a very high likelihood that there is practically no short time-scale reuse of flow label values.

> --------------
> ISSUE 2. RFC 3697 states that flow label values must be unique (for a given address
> pair and within a certain timescale). This requires the node that sets the label
> to keep a list of labels currently in use. That is a significant complication
> for a "stateless" implementation. If the main use of the flow label is for
> load distribution, over a very large number of flows, strict uniqueness
> isn't needed - a 'birthday paradox' level of label collisions is not a problem.
> 
> QUESTION: should this strict uniqueness requirement be relaxed to 'unique with high
> probability'.

From RFC 3697:

 "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 [RND] SHOULD be used."

The only real requirement above is that a random initial value (seed) be used for any sequence (which could also be a pseudo-random sequence). Sounds pretty stateless for me.

Also, the "uniqueness requirement" in RFC 3697 is actually a requirement to "MUST ensure that recently used label values are not unintentionally reused" for other flows, as defined by the source node.

My suggestion is to change the requirement to:

  "A node setting a Flow Label value SHOULD ensure, with a high probability, that it does not unintentionally reuse recently used Flow
   Label values."

Note: text about 120 second quarantine period is dropped. These previously two separate paragraphs could now be combined:

  "A node setting a Flow Label value SHOULD ensure, with a high probability,
   that it does not unintentionally reuse recently used Flow Label values for any given pair of source and destination address.
  To avoid such accidental Flow Label value reuse, a node setting a Flow Label value SHOULD
   select new values in a well-defined pseudo-random sequence and use random seed values that avoid
   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 SHOULD be used."

A new requirement could be added to keep the assigned values consistent:

"Flow Label values MUST be set consistently. When there is a previous non-zero Flow Label value, the new pseudo-random value MUST be the same for all packets for the same set of source and destination addresses and the previous Flow Label value.  When the previous Flow Label value is zero, the requirement is that the assigned pseudo-random Flow Label value be the same for all packets with the same 5-tuple (source and destination addresses and port numbers, and the transport protocol number)."

The above rule could be applied in all nodes setting the flow label values (source, access router, domain exit).

Regards,

  Jarno