'RFC3697bis draft, and rationale, and open issues'

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

List:       ipng
Subject:    RFC3697bis draft, and rationale, and open issues
From:       Brian E Carpenter <brian.e.carpenter () gmail ! com>
Date:       2011-01-31 3:36:49
Message-ID: 4D462E51.3040408 () gmail ! com
[Download RAW message or body]

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

["flowIssues.txt" (text/plain)]

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

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

--------------
ISSUE 3. 3697bis RECOMMENDS pseudo-random flow label values. The goal is be able to 
use just the 3-tuple {dest addr, source addr, label} as input to load
distribution hashes. There have been a couple of objections to this:
 - This property is not required for effective hashes for load distribution;
 - Not all load distribution methods are statistical, so there may be some need for
   deterministic flow label values.
On the other hand, the arguments for formally recommending pseudo-random labels are
that
 - pseudo-randomness has security value (draft-gont-6man-flowlabel-security);
 - pseudo-randomness does have value as input to hashes;
 - a MAY would not have much impact on implementers, so nothing would change.

QUESTION: do we change the recommendation to set pseudo-random flow label values?

--------------
ISSUE 4. The Introduction previously included:

   Doing this [setting the flow label]
   enables load spreading and receiver oriented resource allocation, for
   example.  

The phrase "receiver oriented resource allocation" has been deleted because
we don't know what it means.

QUESTION: Is this deletion OK?

--------------
ISSUE 5. Section 2 says:

   IPv6 nodes MUST NOT assume that the Flow Label value in a incoming
   packet is identical to the value set by the source node.

QUESTION: This needs to be reconciled with the security usage mentioned in 
draft-gont-. Would SHOULD NOT be acceptable?

--------------
ISSUE 6. As noted in Section 3:

QUESTION: Should we incorporate draft-gont- here, or leave it separate?

--------------
ISSUE 7. Section 5 says:

   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 use of the means to specify Flow
   Label values is subject to appropriate privileges (see Section 6.1).
   The source node SHOULD be able to select unused Flow Label values for
   flows not requesting a specific value to be used.

As noted above, in stateless load distribution, occasional duplicate labels
surely don't matter. Also, experience suggests that applications and
transport protocols are unlikely to do any of this, and it isn't
a protocol design issue anyway.

QUESTION: Should we reduce this whole paragraph to a SHOULD or MAY, or even
remove it as out of scope in a protocol spec?

--------------
ISSUE 8. Section 6.1 says:

   Only applications with an appropriate privilege in a sending host
   will be entitled to set a non-zero Flow Label.  Mechanisms for this
   are operating system dependent.  Related policy and authorization
   mechanisms may also be required; for example, in a multi-user host,
   only some users may be entitled to set the Flow Label.  Such
   authorization issues are outside the scope of this specification.

QUESTION: Should this be removed as speculative and out of scope in a 
protocol spec?

--------------
ISSUE 9. The changes to section 2 include this paragraph. Please read all
of it, since the first sentence out of context causes confusion:

   2.  To enable stateless load distribution at any point in the
       Internet, a network domain MUST NOT forward packets outside the
       domain whose flow label values are other than zero or pseudo-
       random.  Neither domain border egress routers nor intermediate
       routers/devices (using a flow-label, for example, as a part of an
       input-key for a load-distribution hash) can determine by
       inspection that a value is not pseudo-random.  Therefore, if
       nodes within a domain ignore the above recommendations to set
       zero or pseudo-random flow label values, and such packets are
       forwarded outside the domain, this would likely result in
       undesirable operational implications (e.g., congestion,
       reordering) for not only the inappropriately flow-labelled
       packets, but also well-behaved flow-labelled packets, during
       forwarding at various intermediate devices.  Thus, a domain must
       protect its peers by never exporting inappropriately labelled
       packets.  This document does not specify the method for enforcing
       this rule.  The suggested way to enforce it is that nodes within
       a domain MUST NOT set the flow label to a non-zero and non-
       pseudo-random number if the packet will leave the domain.  If
       this is not known to be the case, the border router will need to
       change outgoing flow labels.

We've debated and tuned this over several versions of the predecessor
draft. But there are still objections, such as:
 - MUST is too strong, if the downstream operator doesn't care about
   the flow label;
 - We don't fully specify what the border routers must do;
 - We should more fully specify what that hosts must do.
The argument for MUST is that we shoudn't allow an operator
to send packets into the open Internet with badly formed flow labels.
From the Internet's viewpoint, we don't care whether the border router
discards packets, clears the label to zero, or classifies packets and
sets a new pseudo-random label. And if a host doesn't do what is already
recommended, we don't care what it does; the border router has to
hide it.

QUESTION: Should we, and can we, further improve this text?

--------------
ISSUE 10. Section 2 also says:

   Forwarding nodes such as routers and load balancers MUST NOT depend
   only on Flow Label values being randomly distributed.  In any usage
   such as a hash key for load balancing, the Flow Label bits MUST be
   combined with bits from other sources within the packet, so as to
   produce a suitable distribution of hash values.

Why is it restricted to "within the packet"? Couldn't the load balancer
use something else too, especially for a stateful mechanism?

QUESTION: Should "within the packet" be deleted?

--------------
ISSUE 11. In section 3:

   A node that forwards a flow whose flow label value in arriving
   packets is zero MAY set the flow label value.  In that case, it is
   RECOMMENDED that the forwarding node sets the flow label field for a
   flow to a pseudo-random value.

QUESTION: Should we suggest how the forwarding node identifies packets belonging
to the same flow? (draft-ietf-6man-flow-ecmp talks about this.)

--

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

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