Re: Evaluation: draft-ietf-ipv6-flow-label - IPv6 Flow Label Specification

[Alex Zinin <zinin@psg.com>]

>                       Yes  No-Objection  Discuss  Abstain
> Alex Zinin           [   ]     [   ]     [ X ]     [   ]


This document talks about per-flow state establishment and
processing on interim nodes. This is essentially IntServ
and it doesn't scale well.

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.

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.

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.

I think that it would make sense to clearly separate these. 

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? 

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

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. 

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.

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

Ross

At 03:46 PM 8/5/2003 -0700, Alex Zinin wrote:
> This one needs a look too. I thought we
> concluded that IntServ
> doesn't scale, and the doc talks about per-flow processing at
> transit IPv6 nodes...
>
> Token holder: Ross
> Please send comments by Wed night.
>
> -- 
> Alex
> http://www.psg.com/~zinin/

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.

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. 

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.

I think that it would make sense to clearly separate these. 

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? 

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

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. 

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.

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

Ross