Subject: Re: I-D ACTION:draft-chakravorty-bcc-flowlabel-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Apr 2005 15:27:08 +0200

Firstly, when we were developing RFC 3697, we were told very forcefully
by the WG to remove use cases from the draft and simply to define
generic "boundary" semantics. I think exactly the same should apply to
this draft, so all the references to 6LSA should be removed. Then we'll
be able to see more clearly what is actually proposed and whether it will
satisfy other use cases.

Secondly, I think section 3 completely misrepresents RFC 3697. For that
reason I will only comment here on section 3.

>    	-  The static allocation of Flow Labels defining fixed, end-to-end
>    flows in large networks is unwieldy at best. If the specification had
>    allowed for dynamic allocation of Flow Labels as flows were set up
>    and torn down

But it does. The allocation of flows is as dynamic (or as static) as the
sending host wants to make it.

>    (or progressed over multiple hops), the network
>    administrators and/or users would have had the latitude to use one or
>    more labels (in the same flows) - as and when necessary and for
>    different purposes.

A flow, in 3697, is nothing more nor less than the set of packets that
a sending host chooses to label with the same flow label. I could
define every 3rd packet of a TCP session as a flow if I wanted to.
Implementors have complete latitude.

>    The static characteristic of the Flow Label
>    allocation end-to-end and its 3-tuple association with source and
>    destination addresses (which are also static end-to-end) renders the
>    view that the Flow Label is there to extend the address space into
>    the Flow Label field.

It isn't static. (Neither will addresses be, once shim6 is defined
and deployed). It is end to end (see below for why). It certainly
isn't an address space extension - it is quite compatible with 3697
to use the same flow label with different address pairs; it is quite
compatible with 3697 for the nodes to agree on some extra rules
about flow label assignment. All 3697 says is that the 3-tuple MUST be
unique.

> Conversely, one could use the source and
>    destination addresses in conjunction with the Traffic Class field to
>    provide the same services without using the Flow Label at all.

Not at all. The flow label semantics are e2e and the Traffic Class semantics
are domain specific. They are in no sense equivalent.

>    There
>    is no need for a separate static 20-bit field, that has to be used
>    end-to-end, on top of the 256 bits of address space to identify a
>    flow.

An address pair doesn't identify a flow, especially when the rest of
the header is hidden by encryption.

>    	-  Specific flow state establishment methods and the related service
>    models are out of scope in the current label specification [1].

Yes, that was very specific guidance from the WG.

>    Devoid of a methodology for establishing a flow or for provisioning
>    services using established flows meant the Flow Label specification
>    is incomplete

The WG wanted boundary semantics. They didn't want that confused with
use cases.

> and possibly inadequate toward providing implementation
>    and deployment direction for efficient use of the label.

Boundary semantics, by definition, can't be "inadequate" in the strict
English sense of the word. If it means "wrong" that's a different matter,
but has to be justified.
> 
>    	-  As the Flow Label field carries a static, fixed label generated
>    by a source host, for a flow to receive requested treatment in the
>    network, a signaling protocol such as the Label Distribution Protocol
>    (LDP) (used in MPLS) or Resource Reservation Protocol (RSVP) must be
>    used to distribute the label binding (packet classification)
>    information (for this source-based packet classification) to all
>    other nodes in the network.

That is not required. The text assumes a use case that requires other
nodes to have dynamic prior knowledge of the labels in use. There are
uses cases (soft-state load sharing for example) that certainly don't.

>    The current Flow Label specification [1]
>    does not provide any mechanism for propagating label binding
>    information into the network which makes the current Flow Label
>    specification difficult to implement.

As noted, that was specifically missed out to follow the WG's guidance,
and is not needed in all use cases.

> 
>    	-  To ensure that flows can be identified uniquely in the network,
>    the 3-tuple of Flow Label, Source and Destination addresses is used
>    to define a flow. Given the large address field used by the IPv6
>    protocol, the memory requirements for maintaining a flow state that
>    includes two 128-bit addresses and a 20-bit Flow Label (for a total
>    of 276 bits) can be significant when tens of thousands of flows are
>    in operation in a network node. Moreover, the operations used for
>    flow look-ups may also be processing intensive involving multiple
>    memory fetches per flow in 32-bit or 64-bit machines. This is not
>    desirable for small or portable devices with limited memory and
>    processing power.

This is correct to some extent, but since the Internet is largely
stateless, there isn't really any other option at the level of the
boundary semantics. As noted above, a specific use case can very well
add its own signaling mechanism to arrange for whatever stronger
uniqueness semantics it needs. And of course the lookup problem is
susceptible to hash optimization.
> 
>    	-  In IPv6 packets that must traverse errorùprone or unreliable
>    links, errors may inadvertently change the Flow Label bits. As the
>    static Flow Label is to be used end-to-end, the errors may result in
>    flows that can not be matched to any flow (packet) treatment profile.
>    The current specification of Flow Label does not address how errored
>    packets need to be handled or if they can be processed at all in the
>    error-prone links.

Yes, perhaps it should state that they should be handled as default.
In fact 3697 section 2 says

   "If an IPv6 node is not providing flow-specific treatment, it MUST
    ignore the field when receiving or forwarding a packet"

which could be read to include the case of an unknown flow label. But
we would expect level 2 error detection to discard such a packet anyway.

>    Furthermore, errored packets in TCP streams will
>    fail checksums at the destination host resulting in unnecessary
>    retransmissions

They aren't in the least unnecessary. They are very necessary.

>    and possible congestion. 

Congestion?? TCP retransmission tends to have the opposite effect, because
it resets the window.

> (On the other hand, flexible
>    Flow Label as proposed in this document only has local significance
>    and as such has limited vulnerability.)

This is bogus. An errored packet is discarded at level 2 anyway.

> 
>    	-  The fixed label MUST be delivered unchanged to the destination
>    nodes; this even applies to the zero Flow Label which is used for
>    labeling packets that are not part of any flow (for nodes that do not
>    support Flow Label based flows). It is not clear how this requirement
>    contributes any useful functionality.

This was thoroughly debated in the WG, but the short answer is that
it allows the two ends to agree on (for example) a flow-based load
sharing mechanism; and it allows for flow state, if supported, to
be implemented consistently. As far as I recall, the IETF decided
against a label-switching usage of the flow label in 1994 when the
CATNIP proposal was dropped, and decided against it again when 3697
was debated - and both times the feeling was for an e2e flow label.

>    This constitutes an ideal
>    mechanism for man-in-the-middle attacks. What is needed to derail an
>    end-to-end statically defined flow is to simply insert all zeroes in

I wish the text didn't keep repeating the false assertion that 3697 flows
are statically defined. As noted above, they are as dynamic as the
sending host wants them to be.

>    the Flow Label field thus making the flow a 'non-flow'. The flow
>    meant for QoS delivery becomes meaningless 

QOS may not be the only use case, although it may be common.

> and could potentially be
>    harmful to a mission.

Indeed. There are other fields (addresses and traffic class for example)
that a MITM can change with amusing results. If that is a threat,
the operator needs to protect Level 2.

>    	-  Scalability is another issue with the static, fixed Flow Label

They are not static or fixed.

>    assignment. Static assignments are not considered by their very
>    nature scalable. For instance, the projected depletion of the fixed
>    address space in IPv4 has resulted in the adoption of IPv6 (for its
>    huge address space). Flexibility in the assignment of values to a bit
>    field as and when needed is considered in general a good idea.  This
>    is true for the Flow Label as well.

Indeed. That's why we have 20 bits and the broad 3-tuple uniqueness
requirement. We won't run out unless a sending host needs more
than ( 2**20 -1 ) flows to the same destination within two minutes.
I don't think there's a scaling problem.

> 
>    To summarize, the current IPv6 Flow Label is little used; its current

Yes, because we took 10 years to define its boundary semantics, so nobody
knew what to implement before they shipped product.

>    specification is confusing.

I see nothing confusing.

>    Absent an associated mechanism for label
>    binding distribution, the specification provides little in way of
>    functionalities for the IPv6 protocol.

That was entirely intentional.

>    Its application in providing
>    flow based QoS has not been defined,

And we are waiting for use cases to be defined *within* the semantics of
RFC 3697. Flow based QOS could be one of those use cases.

>    its implementation by network
>    devices may prove to be expensive and may introduce issues concerning
>    proper use of the available resources.

Or may not.

>    Its use in the error-prone
>    media is questionable.  It is vulnerable to the man-in-the-middle
>    attacks.

See above comment on the need to protect Level 2 in any case.
> 
>    Finally, the current specification is too restrictive to allow its
>    wide-spread use;

It isn't restrictive; it's actually very permissive except for the
e2e immutability.

> the static allocation of the Flow Label raises

It isn't static.

>    questions regarding its scalability.

It is scaleable.

>    It is safe to assume that
>    emerging applications will find it difficult to take advantage of the
>    current Flow Label specification.

This is true, until we get some use cases specified within the boundary set
by RFC 3697. When I last heard from the 6LSA authors, that is what I understood
they were going to do.

     Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------