Subject: 3697bis diffs

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

Here's a URL that will give you the diffs between RFC 3697 and
draft-ietf-6man-flow-3697bis-00.txt.

http://tinyurl.com/3697bis00-diffs

-- 
Regards
   Brian Carpenter

---

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

Issue 3:

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

Change the recommendation to set pseudo-random flow label values, but also add that all possible re-setting of the value (e.g. on domain exit) be consistent (i.e. a mapping). This mapping can provide the desired randomization of the used label values. Also, this concept can naturally be extended to the case of zero label. In this case the mapping needs to be consistent for the input packet's 5-tuple. 

I provided a text proposal to this effect on the mail about issue 1 & 2.

  Jarno

---

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

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

Full context:

"The minimum level of IPv6 flow support consists of labeling the	
   flows.  IPv6 source nodes supporting the flow labeling MUST be able
   to label known flows (e.g., TCP connections, application streams),
   even if the node itself would not require any flow-specific
   treatment.  Doing this enables load spreading and receiver oriented
   resource reservations, for example."

The phrase "receiver oriented resource allocation" was intended to refer to a case where a receiver of a flow allocated resources for the flow (e.g. on a radio interface). This could be useful where the source considers the traffic best-effort, but where the destination wants/needs better than best-effort treatment (without involving the source in any way).

It is OK for deletion.

---

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

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

IMO "MUST NOT" is proper. What is the case where the receiver COULD assume the flow label to be identical to the value set by the source node?

  Jarno

---

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

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

OK for deletion. See also response to Open issues 1 & 2.

IMO the pseudo-random mandate makes the above text irrelevant.

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

Ditto.

  Jarno

---

From: Jarno Rajahalme <[email-masked]>
Date: Mon, 31 Jan 2011 15:07:13 +0200

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

The fact remains that the receiving domain cannot trust the previous domain to have done the right thing. Therefore:

"If (and only if) the receiving domain makes such use of flow label values, that would benefit from an even pseudo-random distribution, the ingress routers of such domain SHOULD map the received flow labels to new, pseudo-random values. The new values MUST be the same for all packets of any received flow, identified either by a non-zero flow label value (with the source and destination addresses), or, if the received flow label value is zero, by the 5-tuple of the received packet."

I would remove text about domains protecting their neighbors.

  Jarno

---

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

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

"within the packet" ensures consistency, if it refers to address fields. Also, it does not mean ONLY, i.e. other sources (such as a local key) are not excluded. However, don't see how a protocol spec could mandate how a router internal hashing is implemented. At best we could say "SHOULD".

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

Yes. See also my response to issue 9.

  Jarno

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 31 Jan 2011 09:17:47 -0500

Several of these comments have a common theme of requiring domains to 
remark flow-labels on ingress.
While we have agreed to allow remarking of packets with 0 values in 
their flow label, expecting repeated remarking seems to me a very bad idea.
Basically, if we do that, then I expect that most routers will simply 
assume that the flow label is useless, since we can not expect peering 
scale routers to remark the flow label of packets based on deep packet 
inspection.
Also, in many cases, as described in other documents, such re-marking is 
effectively impossible.

Yours,
Joel M. Halpern

On 1/31/2011 8:07 AM, Jarno Rajahalme wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Jarno Rajahalme <[email-masked]>
Date: Mon, 31 Jan 2011 16:42:27 +0200

Joel,

I did not intend to propose that domain-ingress remarking should be mandatory.

If the receiving domain does not critically depend on the received flow label values to be very smoothly distributed, then it has no need for remarking at all.

My point is simply just that IF there is a specific requirement on the distribution of the flow label values, the domain must either provide such distribution itself, or trust someone else to have done that already. Maybe this is self-evident, and need not be mentioned in a protocol spec?

It would be way simpler to allow marking only once (from a non-zero value), with a "pseudo-random" recommendation, and then have the rest of the path just live with whatever value was set. I would be happy with such a text.

However, I'm also OK with text that allows "reasonable" (== consistent) remarking. But that should not be mandated on anyone.

  Jarno

On Jan 31, 2011, at 16:17 , ext Joel M. Halpern wrote:

> Several of these comments have a common theme of requiring domains to remark flow-labels on ingress.
> While we have agreed to allow remarking of packets with 0 values in their flow label, expecting repeated remarking seems to me a very bad idea.
> Basically, if we do that, then I expect that most routers will simply assume that the flow label is useless, since we can not expect peering scale routers to remark the flow label of packets based on deep packet inspection.
> Also, in many cases, as described in other documents, such re-marking is effectively impossible.
> 
> Yours,
> Joel M. Halpern
>