revised ID: draft-ietf-ipv6-flow-label-08.txt

[Thomas Narten <narten@us.ibm.com>]

Alex, Jon,

There is a revised version of the flow-label draft. I've appended the
authors response to your Discuss comments. Please have a look.

I'm also adding it back to the agenda, as it appears we're one vote
shy of the quorum even if the discusses get cleared. :-(

Thomas

From: Brian E Carpenter <brc@zurich.ibm.com>
To: IPv6 <ipv6@ietf.org>
CC: Thomas Narten <narten@us.ibm.com>
Date: Tue, 14 Oct 2003 14:46:55 +0200
Subject: Response to IESG comments on draft-ietf-ipv6-flow-label-07.txt

The IESG comments on this document are at 
https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ipv6-flow-label.bal

It's taken a while for the authors to discover them, but here are our
responses. We'd like the WG's reactions over the next few days, so that
we can update the draft appropriately.

> Ted Hardie (Discuss - August 7, 2003 teleconference Ted 
> reclassified this to a COMMENT):
> This is very mild, and I could be talked out of it on the call,
> but I do find it odd that the key motivational text is in
> section 5.1, in the security requirements. This is the
> text I mean:
> 
> 
>         The goal of the Flow Label is to allow different levels of service to
>         be provided for traffic streams on a common network infrastructure. A
>         variety of techniques may be used to achieve this, but the end result
>         will be that some packets receive different (e.g., better or worse)
>         service than others. The mapping of network traffic to the flow-
>         specific treatment is triggered by the IP addresses and Flow Label
>         value of the IPv6 header,
> 
> This looks to me like it belongs in the introduction, so that the reader
> can understand the impetus to the work.

We think this is correct. Either this duplicates the introduction, or it
belongs in the introduction. In any case, it doesn't belong in the security
section.

> 
> As a side note, I have some concerns about whether any protocol can
> meet the explicit requirements in Section 4 and the implicit requirement
> of "do some good" without running into the maw of some well-known
> dragons, but the statement of requirements looks fair to me.

We think that unspecified dragons are not useful to mention. In any case,
they should be discussed in specific use case drafts, not here. See below
for more comments on use cases.


> Alex Zinin (Discuss):
> 
> This document talks about per-flow state establishment and
> processing on interim nodes. This is essentially IntServ
> and it doesn't scale well.

Not true. The notion of "flow" used here is more general than
in intserv (or NSIS), although the default case of a flow is a single
transport connection. When specific use cases for the flow label are
written up, their individual scaling properties must indeed be documented.

> 
> More comments from rtg-dir (Ross) below.
> 
> General Comments
> 
> It seems to me that the flow label has a purpose, and two possible
> uses. To me the document seems to be not totally clear or perhaps
> even wrong regarding which of the uses is the main one.
> 
> The purpose is to identify flows. For example, this allows the flow to
> be identified using only fields which are in fixed positions in the
> IPv6 Header. This purpose seems to me to be well defined in the
> document.

That is deliberate. The idea of the draft is to tell IPv6 implementors
(both hosts and router) what is the minimum set of functionality they
MUST or SHOULD implement to enable use of the flow label. The draft
doesn't purport to define specific use cases with their various
detailed considerations. In fact, Ross's comment shows that we have done
what we intended in the draft. Perhaps we need a more explicit statement
about this in the introduction.

> 
> Now that you have an indicator regarding what flow a particular packet
> belongs to, what use would you have for this information?
> 
> One possible use is for hashing packets, for example to spread traffic
> across equal cost multi-paths without re-ordering packets from any one
> flow. This seems like a pretty straightforward and sensible use, which
> requires close to zero change to the Internet architecture, and which
> is briefly mentioned in the document.
> 
> The other possible use is for an explicit flow set up procedure.
> However, since the flow are per-{source-address; destination-address;
> flow field} triplet, it would seem that this won't scale much better
> than the current int-serve specification. Thus it is not clear whether
> this will end up being useful in practice. At best I would call this
> experimental.


We can think immediately of at least two other uses - as an e2e label for a
whole class of traffic (coarse grain aggregation), and [this is new from recent
debate inside the multi6 design team] as an e2e label for a multihoming session.

> 
> In some places in the document it appears that the flow field is for
> the purpose of identifying flows, and that either of the two uses
> might be sensible reasons that you might want to identify flows. 

Yes. Exactly.

> In
> other places in the document it looks like the second purpose (which
> to me seems the more speculative) is the reason for the flow field.

It might be. 
> 
> I think that it would make sense to clearly separate these.

What needs to be clearly stated is that specific applications of the
flow label need to be / will be documented in specific use case
documents. We're not sure that there is anything else we can do in the
present draft. Ross's comment is a bit too general to generate specific
text changes.

> More specific comments
>   >> Section 1:
> 
> First three paragraphs do a good job of defining the purpose of the
> flow ID (to allow efficient flow classification based only on fields in
> the fixed part of the IPv6 header).
> 
> Fourth paragraph, first sentence:
>                   The minimum level of IPv6 flow support consists
>                   of labeling the flows.
> 
> In a sense this is reasonable, but I am not sure precisely what it
> means.
> Does this mean:
> 
>                   In order to be an IPv6 conformant node, IPv6 source
>                   nodes MUST be able to label outgoing flows.
> 
> or does this mean:
> 
>                   In order to claim conformance to the IPv6 flow
>                   label specification, IPv6 source nodes MUST support
>                   labeling outgoing flows.
> 
> Or does this mean something else?

The second one. We can clarify this.

> 
>   >> Sections 2 and 3.
> 
> This seems reasonable, and again defines the purpose of the
> flow label in a reasonable way, as well as defining some very
> reasonable requirements, for example specifying how a source
> should set the flow value.
> 
>   >> Proposed New Section Between section 3 and 4:
> 
> It seems to me that the most obviously worthwhile of the
> potential uses of the flow label field is to allow routers to split
> traffic on multiple paths (for example, for load sharing and traffic
> engineering purposes), without having to look past the IPv6
> header.

Thus speaks a routing person...

> 
> One example of where this might be very useful is in the case
> of encapsulation, for example <anything> over IPsec over IPv6
> or <anything> over GRE over IPv6 encapsulations. In this case
> there might be a potentially very large number of high layer flows
> which will be encapsulated with the same IPv6 source and
> destination addresses in the outer IPv6 header. If you can hash
> only on the outer IPv6 addresses, then you could get a lot of
> traffic which is forced to take the same path. If you allow a finer
> grain flow label to be placed in the flow label field, then you can
> get a much more even distribution of traffic across, for example,
> equal cost multi-paths.

Indeed. This is one of the use cases that needs to be written up
in its own document. Not squeezed in here.
 
> I think that it is worth having a section on this possibility. I don't
> think that this requires all that much text.
> 
> There is one question which I have, which could be cleared up
> in such a section: Specifically, the second sentence of section
> 2 states:
> 
>                   A Flow Label of zero is used to indicate packets
>                   not part of any flow.
> 
> Suppose that I am an IPv6 router which is hashing on source
> address, destination address, and flow label, and I am using
> the hash to split traffic among several paths.
> 
> If I see a packet with a flow label of zero, which of the following do
> I assume:
> 
>                   - the node does not implement any flow labelling ability, and
>                       therefore I must hash only on source and destination
> address.
> 
>                   - the node does implement flow labelling, and is telling me
>                       that the packet is not part of any flow, and can therefore
> be
>                       forwarded on any path without regard for re-ordering.
> 
> If we assume the latter, then implementation of the flow labelling
> capability must be supported by all IPv6 source nodes (at least
> to the point of sticking a non-zero value in the flow field), since
> otherwise their packets might be re-ordered by nodes which
> assume that their packets are not part of any flow.

The use of the flow label doesn't affect the desired reordering semantics of the 
Internet, which remain "well, try  not to reorder." So the functional difference 
between the two interpretations is small. In other words we don't intend a zero flow
label to be a license to reorder. In fact we can't see any harm done by including a 
zero flow label in the hash - this will just be the default flow for a given
srce/dest pair. So what? There's no presumption that each flow has a 
similar amount of traffic, anyway.

We should perhaps add an explicit statement that a zero flow label does not
imply that significant reordering is acceptable.

> 
> I would suggest using zero to indicate that flow labelling is not
> supported (and thus routers better keep the packets in order
> based only on source and destination addresses). If we also
> want to indicate that some packets are not part of a flow, we
> might give them a random value, or a different special value.

Well, we just don't see a major semantic difference between "I don't
label flows" and "I decided not to label this packet". Both
require default treatment.
> 
>   >> Section 4:
> 
> The flow state establishment requirements in section 4 seem to be
> very much incomplete. If there were a complete set of flow state
> establishment requirements, then I think that the requirements
> specified in this section are reasonable ones, and would be
> included in the set. However, the two requirements specified in
> section 4 seem to be such a small subset of the complete set of
> requirements that I don't see why it is worth listing them at all. I
> think that it would be cleaner just to say that methods and
> requirements for explicit flow establishment are outside of the
> scope of this document.

No, these are a consensus view of the minimal requirements that all
nodes must satisfy in order to allow co-existence of various different
flow label use cases in the Internet. The individual use cases will
add their own requirements. The WG wanted us to reduce the detail here
to the vital minimum, and that's what we did.

> 
> Naturally if section 4 were removed, then the last phrase of the
> first paragraph of the abstract would also need to be removed
> (page 1, phrase "and the requirements for flow state establishment
> methods"). Similarly the second to last paragraph of section 1
> would need to be abbreviated.
> 
>   >>Section 5:
> 
> First paragraph, last sentence:
> 
>                   Even if the flow label were encrypted, its presence
>                   as a constant value in a fixed position might assist
>                   traffic analysis and cryptoanalysis.
> 
> The flow label is supposed to be unstructured -- in the sense that if
> I am not the source node, then I don't know anything about how the
> source set the label, except that a different value means a different
> flow. As such, I don't understand what encryption would do to change
> the interpretation of a flow label. If two labels were encrypted to
> the same exact value, then it would seem clear that they can't be
> un-encrypted back to different values. If two flow labels were
> encrypted to different values, then as a node in the middle observing
> the packets going by I don't detect any difference.

That's not the point. There have been a few famous crypto breaks in history
due to fixed patterns occurring in the plaintext. The flow label increases
the number of fixed (non-zero) bits in the packet header, and that is
presumably still a cryptographic risk factor as it was in WW 2.

> 
> Section 5.1, second paragraph (top of page 5), first sentence:
> 
>                   Note that there is no guarantee that flow labels sent by a node are
>                   not set in any manner that the node wants to, such as reusing flow
>                   labels, against the recommendations in this document.
> 
> This seems to be a rather awkward sentence, and should probably
> be re-written.

OK
> 
> Additional Topic: Somewhere in the security section (probably in a new
> subsection at the end) it might be worth mentioning that in those
> locations where a firewall or filtering router is employed which looks
> past the IP header to higher level headers, the flow label does
> nothing to eliminate the need to continue to look at the higher
> headers.

OK

> 
> Ross
> 
> Jon Peterson (Discuss):
> 
> Along the same lines as the comments from the Routing Area Directorate, but
> with a few different issues in the text:
> 
> I believe there are two purposes of flows given in the document - first, a
> flow as a way of flagging a stream of related traffic coming from a node
> (following Section 3, first paragraph), and second, a flow as something that
> would be prioritized by routers (following Section 5.1, first paragraph).
> There are a couple of ways in which the two seem to get mixed up.
> 
> 1) In the last paragraph of 5.1, it suggests that a policy decision in the
> source node should be made to determine whether or not an application or
> transport protocol is allowed to use a non-zero Flow Label. But reading, for
> example, the first paragraph of Section 3, the document suggests that "each
> unrelated transport connection and application data stream" on a node should
> be assigned to a new flow (which presumably means that they would have a
> non-zero Flow Label).

Yes, the policy can override the SHOULD. That could be clarified.

> 
> 2) Section 3, second paragraph, 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.
> 
> Given that there is some sort of policy decision associated with the
> assignment of flows, I don't think applications and transport protocols
> could really get to 'specify' these Flow Labels. 

Why not? Consider a use case where we use the flow label at "traffic type"
granularity. A video codec application might want to use different flow labels
for different levels of video encoding. It's not for the IPv6 WG to prevent
that.

> It also isn't clear how
> collisions would be managed (Section 3, third paragraph) if it were possible
> for any multiple applications on the same host to specify Flow Label values.

We deleted a whole lot of implementation recommendations in this area, at the
WG's request. It's entirely algorithmic but it takes you into API and local
state areas that are out of place in a protocol spec. The IP stack has to
cache all flow labels in current use, and whether collisions are allowed or
disallowed is again a use case issue - you might want to use the same
coarse flow label for the audio part of video flows and for VoIP - or you
might not, depending on how you've chosen to use the flow label. Again,
it isn't for the IPv6 WG to legislate on this.

    Brian


-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK

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