Subject: Massaged DISCUSS comments on draft-ietf-ipv6-flow-label

From: Alex Zinin <[email-masked]>
Date: Thu, 7 Aug 2003 16:32:55 -0700

Ross-

 There was a request on the IESG telechat today to see if we can
 clarify the concerns with the document and proposed actions.
 I took the liberty to rearrange your message a bit. Please check
 if you think the text below looks appropriate.

 Also, Thomas believes that this input should be brought to the WG.
 I suspect that we will need to have a conversation with IPv6 people,
 so I suggest that after we finalize the text below, Thomas brings
 it to the WG and we keep rtg-dir cc'ed in the discussion.

Alex

Meta issues:

1. Per-flow state and processing

   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.

   Suggestion:

   remove suggestions to use the flow label for per-flow packet
   processing, or at least provide discussion about scalability
   aspects of this method, and refer to the experience gained with
   IntServ.

2. Clearly separate flow applications

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

3. Flow label zero

   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.

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

Section-specific comments:

Section 1:

  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.

  Suggestion: clarify the text.

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.

  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.

  I think that it is worth having a section on this possibility. I don't
  think that this requires all that much text.
  
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.

  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.

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.

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.

---

From: Thomas Narten <[email-masked]>
Date: Fri, 08 Aug 2003 07:27:03 -0400

Hi Alex and Ross.

A couple of comments, from the view of a recipient that will want to
know what it is that needs to be changed in the document. Note: my
goal here is not to have the big discussion here that this review is
implying, but to tighten up the comments so they can be brought to the
WG most constructively.

Overall, I think  these comments are good and useful. Thanks.

Thomas

>    aspects of this method, and refer to the experience gained with

The purpose is to allow for per-flow processing, so the latter is what
is being requested.

>    to me seems the more speculative) is the reason for the flow

What is the requested action item here? Is there specific text that
can be given as an example of what should be changed? [This can be
read as a vague request to make the document better.]

>         on any path without regard for re-ordering.

Not the latter. One should never in the internet architecture assume
that reording packets is generally OK or to be encouraged.

>    them a random value, or a different special value.

I agree that this general point deserves more thinking and maybe
clearer text. The fundamental question seems to be whether a flow
label of 0 means "source does not implement flows" or "source
implements flows, but this packet is not to be given any flow-specific
treatment". Or whether the distinction is important in practice.

---

From: Ross Callon <[email-masked]>
Date: Fri, 08 Aug 2003 15:17:20 -0400

>  it to the WG and we keep rtg-dir cc'ed in the discussion.

I agree that if these points are to be made, and if the IESG agrees,
then either (i) the comments should come from the IESG and rtg-dir 
should be CC'd; or (ii) the comments could be first discussed with 
some of the authors off line and then brought to the working group
either as IESG comments or as author's proposed resolution to 
IESG comments (still with rtg-dir CC'd). 

Regarding meta-issues, I think that the main meta issue is that 
the document includes three things: (i) A definition of the flow 
field, including directions on how the source should set this and
what can be assumed from the field; (ii) The notion that the field
may be useful for routers to hash packets without having to look
past the IPv6 header; and (iii) The notion that this field may be
used as part of a procedure which keeps explicit flow state in
routers, likely by making use of explicit signaling. 

The first of these three is well defined, except for one small detail 
regarding a value of zero (which I think can be cleared up quickly). 
The second of these is well defined and can be expressed in very
few words (ie, so few words that it doesn't seem worth having a
separate document just for the purpose). The third of these is
not well defined at all, and will require significant additional work 
to fully define. I don't think that we should stop this work, but
rather just take it to a separate document. 

With this in mind, how about the following re-wording of Alex's
re-wording:

Meta issues:

1. Scope of the document.

    The document combines three important ideas, two of which are 
    well defined, and one of which is less well defined and will require
    additional work. We would suggest that the well-defined ideas are
    left in the document, and the less well defined idea is moved to a
    separate document. (specific edits are proposed below). 

    Specifically, the document talks about: (i) The definition of the flow 
    field, including directions on how the source should set this and
    what can be assumed from the field; (ii) The notion that the field
    may be useful for routers to hash packets without having to look
    past the IPv6 header; and (iii) The notion that this field may be
    used as part of a procedure which keeps explicit flow state in
    routers, likely by making use of explicit signaling. 

    The first two of these (modulo a detail discussed below) are well 
    defined and should be able to be progressed with limited additional
    work and editing. The third of these might require significant 
    additional work before it is completed. 

2. Per-flow state and processing

    The flow label provides an indicator regarding what flow a particular packet
    belongs to. Given this, what use would you have for this information?

    this will end up being useful in practice. Perhaps this could be called
    experimental.

    Suggestion:

    Remove suggestions to use the flow label for per-flow packet
    processing (and possibly reference "work in progress" which is
    outside the scope of the document), or at least provide discussion 
    about the scalability aspects of this method, and refer to the 
    experience gained with IntServ.

3. Clearly separate flow applications

4. Flow label zero (more detailed comment)

    Suggestion:

    Possible text might be:

            A Flow Label of zero is used to indicate packets which are
            not part of a separately identified flow, or are from a source
            which does not support the flow label. Since such packets
            might be related as part of a unidentified flow, the required
            treatment and order preservation is the same as would be
            expected for IP traffic in the absence of a flow label. 

Section 1:

    or does this mean:

    It seems to me that the most straightforward 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.

   
Section 4:

    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. In this case it might be desired to 
    add a short description to the introduction stating something
    like:

           The flow label may potentially also be used to support per-flow 
           explicit packet handling based on per-flow state. Requirements
           and procedures for this purpose are outside of the scope of this
           document [reference ongoing work in this area, if any].

Section 5:

    Suggestion: Perhaps the sentence could be re-written as follows:

          Even if the flow label were encrypted, the fact that different
          labels would typically be encrypted to different values 
          implies that it can be used to distinguish flows, and therefore 
          that it might assist traffic analysis and cryptoanalysis.

Section 5.1

Additional Topic:

---

From: Ross Callon <[email-masked]>
Date: Fri, 08 Aug 2003 13:59:34 -0400

>implying, but to tighten up the comments so they can be brought to the

Thomas;

I think that it works best to reply to the more specific comments
in your message first, and then go back to Alex's message. 

>The purpose is to allow for per-flow processing, so the latter is what

But the field is useful for two uses. Thus it makes sense to separate
the users, while having a clear specification of what the flow field
specifies.

I agree that some in the working group want it specifically for per-flow
setup and processing. I don't think that we want to preclude this as a
standards issue (whether it is precluded by the cost of building a 
device which is capable of dealing with enough flows is in my opinion
not what we are trying to answer here. 

>read as a vague request to make the document better.]

I will see if I can produce draft text. 

>that reording packets is generally OK or to be encouraged.

The spec currently states that a value of zero indicates that the 
packet is not part of any flow. Perhaps it should state that a 
value of zero indicates that the packet is part of a flow which 
is not clearly differentiated through use of the flow label. 

>treatment". Or whether the distinction is important in practice.

I think that it should be clear what you are allowed to do with a
packet whose flow label is zero. ;-)

Ross