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

From: Alex Zinin <[email-masked]>
Date: Wed, 5 Nov 2003 19:55:36 -0800

Thomas,

See inline below.
Ross, please check the answers to your comments.

Alex

> 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 <[email-masked]>
> To: IPv6 <[email-masked]>
> CC: Thomas Narten <[email-masked]>
> 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.

I could probably live with this if the document made it clear that
establishing state for each individual fine-granularity flow on the
interim nodes dealing with gigs of traffic is not a goal. Basically,
what I'm looking for is the scalability discussion.

I'm leaving the rest to Russ.

Alex

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

does e2e imply that _all_ interim nodes need to have state for it
or that edge nodes only need it?

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