Subject: draft-wang-6man-flow-label-reflection

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 09:43:24 +0100

As the words ICMPv6 nor "Packet Too Big" are in this draft it already
has big problems.

ICMPv6 is part of a "Flow" as it signals errors related that flow.

Hence, not having a mention of them makes that draft not work.

Further see:
 http://datatracker.ietf.org/doc/draft-v6ops-pmtud-ecmp-problem/

For a writeup why the Flow Label is broken.

Note also that as "Flow Label" is supposed to be used for Load
Balancing, but I have not found a hardware device yet that is actually
using it for that purpose, they just look at src + dst and optionally
ports if they want to go that low...

As stated elsewhere: the 20 bits of the Flow Label are a waste of header
space.

Greets,
 Jeroen

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 14 Nov 2014 17:52:48 +0000

Hi, Jeroen,

We can certainly add some consideration in the future version regarding to ICMPv6 and "Packet too big". However, could you be more specific what your concern is regarding to ICMPv6 and flow label reflection?

BTW, the v6ops draft you mentioned does not have any discussion regarding to flow label.

Regards,

Sheng
________________________________________
From: ipv6 [[email-masked]] on behalf of Jeroen Massar [[email-masked]]
Sent: 14 November 2014 16:43
To: 6man WG
Subject: draft-wang-6man-flow-label-reflection

Further see:

Greets,
 Jeroen

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

---

From: joel jaeggli <[email-masked]>
Date: Fri, 14 Nov 2014 08:33:43 -1000

On 11/14/14 7:52 AM, Sheng Jiang wrote:
> Hi, Jeroen,
> 
> We can certainly add some consideration in the future version
> regarding to ICMPv6 and "Packet too big". However, could you be more
> specific what your concern is regarding to ICMPv6 and flow label
> reflection?
> 

20 bits alone isn't enough to identify a flow, certainly not when the
source has changed. I have more flows then that on a single path.

this doesn't help at all with hashing where you would be forced to use
dest + flow label to make any sense of of this becuase that's going to
be lumpy as hell given number of flows with 0 flow label and a finite
number of dests

> Regards,
> 
> Sheng ________________________________________ From: ipv6
> [[email-masked]] on behalf of Jeroen Massar
> [[email-masked]] Sent: 14 November 2014 16:43 To: 6man WG Subject:
> draft-wang-6man-flow-label-reflection
> 
> As the words ICMPv6 nor "Packet Too Big" are in this draft it
> already has big problems.
> 
> Balancing, but I have not found a hardware device yet that is
> actually using it for that purpose, they just look at src + dst and
> optionally ports if they want to go that low...
> 
> As stated elsewhere: the 20 bits of the Flow Label are a waste of
> header space.
> 
> Greets, Jeroen
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Nov 2014 08:01:12 +1300

> source has changed. I have more flows then that on a single path.

For load balancing, that doesn't really matter too much, but if you
were really trying to identify flows individually, you have to use
{src-addr, flow-label} just by the definition of the flow label. With
a reflected label that isn't safe, because the rule that the source
must ensure that {src-addr, flow-label} is unique cannot be guaranteed
by the reflector.

    Brian

> ------------------------------------------------------------------------
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 14 Nov 2014 19:41:20 +0000

> must ensure that {src-addr, flow-label} is unique cannot be guaranteed

Well, and then there is the question of what constitutes a "flow" from the perspective of the party in question. For RFC 6057 purposes, a flow is the traffic that comes from a given subscriber. From an ISP perspective, it is the traffic for which a stated SLA applies, typically the traffic from a given neighboring AS, the traffic between two neighboring AS's, or the traffic related to a given customer network. For a load balancer such as Joel might operate, it often needs to be additionally qualified, such as "an HTTP session that is requesting a specific kind of content". Any place except the very edge, it is rarely specifically identified by a five-tuple, and rarely something that would be derived from a random number generator.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Nov 2014 09:09:10 +1300

> Well, and then there is the question of what constitutes a "flow" from the perspective of the party in question. For RFC 6057 purposes, a flow is the traffic that comes from a given subscriber. Fro…

Sure, which is why the stateless flow label model assumes a good quality
hash function, not a pseudo-random number generator. And actually the
first sentence of RFC 6437 says "a flow is a sequence of packets sent
from a particular source to a particular unicast, anycast, or multicast
destination that a node desires to label as a flow." That was carefully
drafted.

    Brian

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 22:01:43 +0100

> must ensure that {src-addr, flow-label} is unique cannot be guaranteed

And also note that any router on the path is allowed (they "MAY") per
the RFC to overwrite the label if they see fit.

The primary use of the Flow Label seems to be Load Balancing, but load
balancing does not work as doing that based on src/flow-label or just
flow-label breaks ICMPv6 PTBs.

As such, the primary use case of Flow Labels is broken. Thus making that
field useless.

I am sorry for not noticing back then that this was being redefined nor
having the insight that is there today, otherwise I would have commented
as such...

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 22:04:27 +0100

On 2014-11-14 21:09, Brian E Carpenter wrote:
> hash function, not a pseudo-random number generator.

The 20 bits of randomness in the Flow Label does not add anything extra
to the 128bits of IPv6 source address, or the bonus of 128bits
destination, or the possibly 2x 16 bits from a source/dest port.

Most balancers are more than happy to just use the source btw, as that
way a source hammering away will be stuck on the same cluster and that
only slows down one backend instead of saturating all the others too.

> And actually the

While it might be "carefully drafted" it is unfortunately not something
that can actually be used in real life.

The Load Balancers this is intended for cannot use it. Hence, Flow Label
is not used and thus useless.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Nov 2014 10:13:08 +1300

> the RFC to overwrite the label if they see fit.

Once the label is set, that is not true (but there is an exception for
paranoid firewalls). In reality the field can be forged, but so can
anything in the IPv6 header.

> flow-label breaks ICMPv6 PTBs.

That case is broken with or without the flow label.

> As such, the primary use case of Flow Labels is broken. Thus making that

No, it's stateless load balancing with fragmentation that's broken.

   Brian

---

From: Steven Blake <[email-masked]>
Date: Fri, 14 Nov 2014 16:18:16 -0500

> As such, the primary use case of Flow Labels is broken. Thus making that

Using address(es) + flow label as a load-balancing hash key is just as
(un)broken as using address(es) + port(s) with respect to ICMPv6 PTBs.
But it does have the virtue of being transport protocol-independent and
at a fixed header offset.

Regards,

// Steve

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 22:31:59 +0100

On 2014-11-14 22:13, Brian E Carpenter wrote:
[..]
> That case is broken with or without the flow label.

Thus you are saying that we do not need the Flow Label?

Because which case is left then?

> No, it's stateless load balancing with fragmentation that's broken.

Stateful load balancing works also without the Flow Label.

And application layer proxies, eg a HTTP proxy (the way Load Balancing
used to be done), does not have a use for a Flow Label either.

Hence, which case for using the Flow Label is there?

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 22:33:12 +0100

> at a fixed header offset.

There is little hash difference between:

HASH(src + dst)

and:

HASH(src + dst + random-number-chosen-by-dest-that-is-always-0)

Thus please, where is this Flow Label useful for?

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 22:43:24 +0100

> source has changed. I have more flows then that on a single path.

I hear you there ;)

It is only a bit shy of a max of 1 million combos.

> be lumpy as hell given number of flows with 0 flow label and a finite

That is a study I have to do. Will try to get around to that this
weekend by deploying something in SixXS.

Would be great if an org like Google could do a similar study, seeing
how they are effectively capturing and analyzing all packets any way...

Greets,
 Jeroen

---

From: Steven Blake <[email-masked]>
Date: Fri, 14 Nov 2014 16:46:06 -0500

> Thus please, where is this Flow Label useful for?

In the use case we are discussing, dst is constant (the anycast
address).  So the choice is between src-only or src + flow label as the
source of entropy.  Maybe that is irrelevant for the "stateless load
balancer sitting in front of a farm of web-servers" use case, but there
are other uses for load balancing, including ones where it is useful to
split the load to/from a single host.  And hopefully IPv6 will outlive
our current web architecture and the dominance of TCP/UDP.

Regards,

// Steve

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 14 Nov 2014 23:26:40 +0100

On 2014-11-14 18:52, Sheng Jiang wrote:
> Hi, Jeroen,
> 
> We can certainly add some consideration in the future version regarding
> to ICMPv6 and "Packet too big".

Without it, it is quite futile to document more about Flow Labels...

> However, could you be more specific what your concern is regarding to ICMPv6 and flow label reflection?

See the below mentioned draft and the whole thread about Flow Labels...

> BTW, the v6ops draft you mentioned does not have any discussion regarding to flow label.

The word "Flow Label" is hidden in the ECMP calculation.

Greets,
 Jeroen

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 14 Nov 2014 22:48:02 +0000

>From: Jeroen Massar [[email-masked]]
>

Even there is failure in ECMP use case, it does not mean failure for other use cases.

Sheng

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 15 Nov 2014 00:38:54 +0100

> Even there is failure in ECMP use case, it does not mean failure for other use cases.

As the load balancing use case is the number one reason for the Flow
Label to have an existance, which other use cases would that be?

Greets,
 Jeroen

---

From: "Aijun Wang" <[email-masked]>
Date: Sat, 15 Nov 2014 09:05:56 +0800

Hi, Jeroen:

Service Provider wants to apply the same policy to the upstream and
downstream of one session, or more accurately, apply the policy to
downstream of one session based on the recognition of it upstream packet.
The flow label can be used to identify the unique session between one pair
of IPv6 hosts, and alleviate the burden for the network device to recognize
the downstream packet, for example, http response packet. We think this is
one appropriate use case for the flow label.

Best Regards. 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Jeroen Massar
Sent: Saturday, November 15, 2014 7:39 AM
To: Sheng Jiang; 6man WG
Subject: Re: draft-wang-6man-flow-label-reflection

> Even there is failure in ECMP use case, it does not mean failure for other
use cases.

As the load balancing use case is the number one reason for the Flow Label
to have an existance, which other use cases would that be?

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 15 Nov 2014 03:51:28 +0100

> one appropriate use case for the flow label.

The Flow Label as defined tells you nothing about the contents of the
flow. Hence nothing to prioritise on there. You will still have to look
at the typical five tuple and likely deeper when everything is just
going to look like HTTP.

Oh, and IPv6 Errors (ICMPv6) are part of that flow, but the Flow Label
will not include those.

And as you say "Service Provider" though, sounds like you are opening
that can of worms called Net Neutrality.

Greets,
 Jeroen

---

From: Florent Fourcot <[email-masked]>
Date: Sat, 15 Nov 2014 12:41:37 +0100

Hello,

> but I have not found a hardware device yet that is actually
> using it for that purpose,

You are aware of the ECMP problem, so you should know that the Linux
kernel already use flow labels for that. And it is embedded in many
hardwares.

Some links:

 * http://patchwork.ozlabs.org/patch/343108/
 * http://permalink.gmane.org/gmane.linux.network/321696

Best regards,

-- 
Florent Fourcot.

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 17 Nov 2014 09:35:13 +0800

Hi, Jeroen

Please see the reply inline below.

> From: Jeroen Massar [mailto:[email-masked]]
> Sent: Saturday, November 15, 2014 10:51 AM
> To: Aijun Wang; 'Sheng Jiang'; '6man WG'
> > The flow label can be used to identify the unique session between 
> > one pair of IPv6 hosts, and alleviate the burden for the network 
> > device to recognize the downstream packet, for example, http 
> > response packet. We think this is one appropriate use case for the flow
label.
> The Flow Label as defined tells you nothing about the contents of the
flow.
> Hence nothing to prioritise on there. You will still have to look at 
> the typical five tuple and likely deeper when everything is just going to
look like HTTP.
【Aijun】: with the reflection mechanism, we only need the deeper
information of upstream packet, not necessary for the corresponding
downstream packet. For downstream packets of the same session, the 3-tuple
info(src, dst, flow label) is enough for upper layer traffic recognition. 
We also consider other usage scenarios for flow label reflection, for detail
information, you can review
http://datatracker.ietf.org/doc/draft-wang-6man-flow-label-reflection/ in
more detail. The presentation document(the link on the current IETF website)
seems to connect the wrong file) 

> Oh, and IPv6 Errors (ICMPv6) are part of that flow, but the Flow Label 
【Aijun】：ICMP Errors packets are often regenerated by the router, not the
original data packet destination(3-tuple information has been changed). So
the process for flow label reflection would be different and we will
consider it more carefully later.
For PTB error message in ECMP environment, especially for the load balancer
before server farm, we recommend the load balancer to deal with specially
such PTB error message, that is to say, send this error message to all
servers that have the same address. Such method is more simple and less
influences to redefine the meaning of this field. Servers that receive the
PTB error message should all reduce their following packet size according to
the recommending MTU value.

> that can of worms called Net Neutrality.
【Aijun】: SFC, NFVRG etc group in IETF are all considering how to deal with
various traffic flow in more flexible manner, this is the development trend.
It is not enough for service provider to consider only the ip src and ip
dest information.

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 17 Nov 2014 09:10:05 +0800

Hi, Jeroen

> > The flow label can be used to identify the unique session between one
> > pair of IPv6 hosts, and alleviate the burden for the network device to
> > recognize the downstream packet, for example, http response packet. We
> > think this is one appropriate use case for the flow label.
> 
flow.
> Hence nothing to prioritise on there. You will still have to look at the
typical five
> tuple and likely deeper when everything is just going to look like HTTP.
> 
【Aijun】: with the reflection mechanism, we only need to the deeper
information of upstream packet, not necessary for the corresponding
downstream packet. For downstream packets of the same session, the 3-tuple
info(src, dst, flow label) is enough for upper layer traffic recognition. 
We also consider other usage scenarios for flow label reflection, for detail
information, you can review the presentation document(the link on the
current IETF website connect to the wrong file, then I attached it via
e-mail.) 

> Oh, and IPv6 Errors (ICMPv6) are part of that flow, but the Flow Label
will not
> include those.

> And as you say "Service Provider" though, sounds like you are opening that
can
> of worms called Net Neutrality.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 17 Nov 2014 09:02:58 +0100

> info(src, dst, flow label) is enough for upper layer traffic recognition. 

It will be enough IF the source host sets it AND the destination
reflects it. As the redefinition of the Flow Label (the bunch of RFCs
from end of 2011) have not made it into hosts stacks yet almost 3 years
later and lots of people do not upgrade. When do you expect this to happen?

But more importantly, do you think the Operator community can actually
use it?

See below for more about that.

> current IETF website connect to the wrong file, then I attached it via

Those "Usage Scenarios" should be in your draft. That is the only way
people can properly comment on them.

> consider it more carefully later.

As you are attempting to change this whole Flow Label mechanism (again),
please consider how to handle this _now_ and not another RFC later.

The Flow Label for "flow identification" is useless without ICMPv6
Errors being part of the flow as it typically indicates why that
specific flow has ended.

In the case of IPFIX/NetFlow you will find that there you also get two
flows: one for instance for TCP and another for ICMPv6. Only the better
IPFIX/NetFlow analyzers out there are able to bind together the two so
that the first (the TCP Flow) has the detail of why it was ended (eg
Port Unreachable).

> servers that have the same address.

And then an attacker sends a few thousand ICMPv6 PTBs and your load
balancer then nicely explodes that to the 1000 servers in the farm
behind it, yeah, that is going to scale.

As you see, that is not an answer. No operator would want to see that.
They are much better off just limiting the Internet to a MTU of 1280 as
that is a safe thing to do.

> Such method is more simple and less
> influences to redefine the meaning of this field.

Your approach does not simplify anything.

It does provide a great attack vector.

As there are papers like this out:
http://christian-rossow.de/publications/amplification-ndss2014.pdf

Operators will do anything to minimize any kind of amplification attacks
on their infrastructures.

> Servers that receive the

They MUST NEVER do that. They should only lower MTU when the payload
packet in the ICMPv6 matches a packet that they could have sent.

Though indeed, the only thing that could happen is that the MTU becomes
1280, that is still a bad idea.

As most stacks stuff the Path MTU in a per-destination route though
those hosts likely do not have an entry and it would be discarded anyway.

> It is not enough for service provider to consider only the ip src and ip

Indeed just the src/dst pair is not enough.

But realize that an extra random number ("Flow Label") chosen by the
source host is not going to give these kind of folks the information
they want anyway.

They will just do what they have been doing for well over a decade: src
+ dst + proto + src & dst ports

As that does give them a reasonable assumption of what they are looking at.

The "Flow Label" is not giving them any details whatsoever.

Greets,
 Jeroen

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 18 Nov 2014 00:32:38 +0000 (UTC)

>________________________________
> From: Jeroen Massar <[email-masked]>
>To: Aijun Wang <[email-masked]>; 'Sheng Jiang' <[email-masked]>; '6man WG' <[email-masked]> 
>Sent: Monday, 17 November 2014, 19:02

<snip>

It's in the Linux 3.17 kernel (which has just hit Fedora 20), although not switched on by default, so that it doesn't interfere with 'flow label manager' (I don't know what that is.) According to the comments, it is also implemented in the FreeBSD kernel and enabled by default. Finally, as it was implemented by Tom Herbert from Google, it implies that Google see value in it, and possibly have a wide scale use for it.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cb1ce2ef387b01686469487edd45994872d52d73

>But more importantly, do you think the Operator community can actually
<snip>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 18 Nov 2014 09:42:27 +0800

Hi, Jeroen

Please see the reply for your concern below.

> Sent: Monday, November 17, 2014 4:03 PM
> >> the
> > downstream packet. For downstream packets of the same session, the
> > 3-tuple info(src, dst, flow label) is enough for upper layer traffic
recognition.
> 
> It will be enough IF the source host sets it AND the destination reflects
it. As
> the redefinition of the Flow Label (the bunch of RFCs from end of 2011)
have not
> made it into hosts stacks yet almost 3 years later and lots of people do
not
> upgrade. When do you expect this to happen?
> 
> But more importantly, do you think the Operator community can actually use
> it?
> 
【Aijun】: When the IPv6 traffic are dominant in the internet, the analysis
for application traffic that based on IPv6 will increased, the flow label
filed will be exploited gradually.  RFC6437 give detail the generation rule
for this field and why use this filed instead of the 5-tuple to identify one
specific flow:
 
   "Traditionally, flow classifiers have been based on the 5-tuple of the
source address, destination address, source port, destination port, and the
transport protocol type.  However, some of these fields may be unavailable
due to either fragmentation or encryption, or locating them past a chain of
IPv6 extension headers may be inefficient. Additionally, if classifiers
depend only on IP-layer headers, later introduction of alternative
transport-layer protocols will be easier."

For service operator, they are eager to know the application traffic
distribution within their network, not just the total traffic volume and
every link's usage. For IPv4-based packet, they must know such info via
5-tuple message of one packet or via some deep analysis devices in both
directions. For IPv6 packet, such process can be simpler if they use the
flow label and flow label reflection mechanism-----the flow label is in IPv6
fix header potion and the flow label reflection mechanism can correlate the
upstream and downstream of one session together easily.

> > We also consider other usage scenarios for flow label reflection, for
> > detail information, you can review the presentation document(the link
> > on the current IETF website connect to the wrong file, then I attached
> > it via
> > e-mail.)
> 
people
> can properly comment on them.
> 
【Aijun】:The "Usage Scenarios" are also described in
http://datatracker.ietf.org/doc/draft-wang-6man-flow-label-reflection/?inclu
de_text=1 section 5. The presentation document may be more vivid due to some
colorful sketch. That's the reason I recommend you to refer the presentation
document.

> > 【Aijun】：ICMP Errors packets are often regenerated by the router, not
> > the original data packet destination(3-tuple information has been
> > changed). So the process for flow label reflection would be different
> > and we will consider it more carefully later.
> 
> The Flow Label for "flow identification" is useless without ICMPv6 Errors
being
> part of the flow as it typically indicates why that specific flow has
ended.
【Aijun】: The original flow info can be gotten from the message body of
ICMP error message. As the RFC4443 section 2.4 sub clause c) 'description:
"Every ICMPv6 error message (type < 128) MUST include as much of the IPv6
offending (invoking) packet (the packet that caused the error) as possible
without making the error message packet exceed the minimum IPv6 MTU", the
(src,dest, flowlabel) of this part can be used to identify which specific
flow cause the ICMP error.

What we are considering is how to set the flow label value of the ICMP error
message itself(the outer part). Does it need to copy the original packet's
value or not.
> IPFIX/NetFlow analyzers out there are able to bind together the two so
that the
> first (the TCP Flow) has the detail of why it was ended (eg Port
Unreachable).

【Aijun】As you mentioned here, then it seems more reasonable to copy the
flow label info of the original packet to the same field of its
corresponding ICMP error message. The IPFIX/Netflow then can easily know
which source, which flow cause the generation of ICMP error message. If you
agree with this, we can add it into our draft later.

> 
> > For PTB error message in ECMP environment, especially for the load
> > balancer before server farm, we recommend the load balancer to deal
> > with specially such PTB error message, that is to say, send this error
> > message to all servers that have the same address.
> 
> balancer then nicely explodes that to the 1000 servers in the farm behind
it,
> yeah, that is going to scale.
> 
that is a
> safe thing to do.
【Aijun】: The reason that I consider the servers in one cluster should all
receive such PTB message is that if only one server receive and change the
MTU of its output packet, when load balancer allocate to traffic to another
server in next round, the new selected server will still encounter the PTB
error message and increase the TCP and application process dealy.  Actually,
there may exist some attack explosion influences, but I think it should be
considered and mitigated by the load balancer. 
The process of DHCP DISCOVERY/OFFER/REQUEST/ACKNOWLEDGE uses the similar
notify mechanism, to inform other DHCP servers that one of the server in the
broadcast domain has served the client.

> http://christian-rossow.de/publications/amplification-ndss2014.pdf
【Aijun】: I can't download this document, would you like to send it to me
individually?

> Operators will do anything to minimize any kind of amplification attacks
on their
> infrastructures.
> 
> > Servers that receive the
> > PTB error message should all reduce their following packet size
> > according to the recommending MTU value.
> 

【Aijun】: Please see the explain above.

> Though indeed, the only thing that could happen is that the MTU becomes
1280,
> that is still a bad idea.
> 
> As most stacks stuff the Path MTU in a per-destination route though those
> hosts likely do not have an entry and it would be discarded anyway.
> 
> >> that
> > 【Aijun】: SFC, NFVRG etc group in IETF are all considering how to deal
> > with various traffic flow in more flexible manner, this is the
development
> trend.
> > It is not enough for service provider to consider only the ip src and
> > ip dest information.
> 
source
> host is not going to give these kind of folks the information they want
anyway.
> The "Flow Label" is not giving them any details whatsoever.

【Aijun】: we only need the "flow label" to identify one unique flow between
two hosts. Based on the flow label filed and flow label reflection, the
service provider need only do the deep analysis work once and can understand
such traffic in other places, in both direction.  SFC, NFVRG etc. group can
also benefit from this filed in future.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 03:22:32 +0100

On 2014-11-18 02:42, Aijun Wang wrote:
[..]
> filed will be exploited gradually.

Why would they use it?

[..]
> every link's usage.

As the Flow Label does not identify any application, how is the above
relevant?

> For IPv4-based packet, they must know such info via

The Flow Label is a random number. It does not identify anything.

As such, the 5-tuple is a lot more worthy than that.

> colorful sketch. That's the reason I recommend you to refer the presentation

You will want to remove this section completely:
8<-------------
   There is rapidly increasing requirement from service providers (SP)
   to cooperate with the content providers (CP) to provide more accurate
   services and charging policies based on accurate traffic recognition."
---------->8

You are basically describing that they will be charging based on
content. That completely defies any kind of "Net Neutrality". Definitely
not something the IETF wants to promote.

Also due to a rather bad connotation of the abbreviation, please do not
use "CP".

Note also, that as the Flow Label is a random number, it does not add
any value to the information already known (typically that the Content
Provider only has a single service on that IP/port).

As such, that is not a good useage scenario.

"5.2.  Flow Label Reflection for Bi-direction Tunnels"

Tunnel providers KNOW what is in the inside. And typically these folks
(think: anonymous VPN) will not want to expose any traffic relation anyway.

Hence, they will not properly use the Flow Label, which still is a
random number, and the src+dst address will tell you the same thing:
some user is sending traffic from src to dst.

"5.3.  Flow Label Reflection on edge devices" has "the service provider
could always use it for bi-directional traffic recognition."

That they can do that is one, but they can already do that based on
other properties.... thus why would they do it this way?

I am very sorry, but I really do not see any need for the Flow Label.
Let alone bothering 'reflecting' it.

> flow cause the ICMP error.

While that is great. Load Balancers, those things that are described to
be the primary use of Flow Labels, do not do that. This as they do not
want to look beyond the first 40 bytes of the IPv6 header.

If they can look after the 40 bytes, then they can just as well check
the TCP and UDP ports. Why bother with a Flow Label?

> message itself(the outer part). Does it need to copy the original packet's

It would be very useful. But it requires all the hosts in the world to
do so.

Seeing the little uptake of the last revision of the Flow Label
demonstrates that this is not going to happen.

Especially as folks are getting more and more privacy conscious. Note
that the IETF has a mandate around that too now.

> agree with this, we can add it into our draft later.

But that would require redefining the Flow Label completely and getting
that deployed world wide, which is not going to happen...

Note also that folks doing IPFIX/NetFlow already HAS the capability of
matching these up as processing IPFIX/NetFlow can be done really fast.

The problem is that one cannot do that at line-rate in a load balancer,
which will not bother with checking these things.

> error message and increase the TCP and application process dealy.

The ECMP hash is stable. Thus unless the server is replaced with
another, thus the final/real destination will not change that often.

Much less often than broadcasting a single packet to all your 1000
backends at least.

> Actually,

The 'mitigation' at those speeds is: rate limit.

Hence, it will break various setups.

> broadcast domain has served the client.

DHCP is not done at several gigabits/second...

> 【Aijun】: I can't download this document, would you like to send it to me

Google/Bing/Yahoo/etc for "Amplification Hell: Revisiting
Network Protocols for DDoS Abuse"

eg also at:
http://www.internetsociety.org/sites/default/files/01_5.pdf

There is lots of copies of this around as it is a really important
document to be aware of.

> 【Aijun】: Please see the explain above.

That does not explain why you would want to restrict your whole server
farm to such a low MTU...

[..]
> also benefit from this filed in future.

Here you state that they will do "deep analysis work".

Why do we need a Flow Label then?

Please note that a five-tuple is perfectly fine for making up a random
id so that one "only has to do deep analysis work once". This is what
people have been using for as long a they have been doing this kind of work.

Greets,
 Jeroen

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Nov 2014 14:48:59 +1100

> people have been using for as long a they have been doing this kind of 

And it doesn't work with IPv4 either.  Fragmented IPv4 traffic also
fails to be correctly forwarded by load balancers which look at TCP
and UDP ports.

Just because it works "most of the time" doesn't mean that it isn't
broken.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 18 Nov 2014 06:33:11 +0000 (UTC)

----- Original Message -----
> From: Mark Andrews <[email-masked]>
> To: Jeroen Massar <[email-masked]>
> Cc: '6man WG' <[email-masked]>
> Sent: Tuesday, 18 November 2014, 14:48

And layer 2 load balancing i.e. LAG also fails for either fragments or when the transport layer protocol isn't TCP or UDP. Encoding flow information in the flow label overcomes that issue too.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 18 Nov 2014 08:53:54 +0100

On 2014-11-18 07:33, Mark ZZZ Smith wrote:
[..]
> And layer 2 load balancing i.e. LAG also fails for either fragments
> or when the transport layer protocol isn't TCP or UDP.

Another thing that we really need to deprecate: IPv6 fragments.

Why are:
https://datatracker.ietf.org/doc/draft-bonica-6man-frag-deprecate/
https://datatracker.ietf.org/doc/draft-taylor-v6ops-fragdrop/

not active or already an RFC?

> Encoding flow information in the flow label overcomes that issue too.

But that is the thing: the Flow Label is a random number.

Entities that do not want to be tracked will set it to 0 or randomize it
per packet.

There is thus no "information" in that field: it is random.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Nov 2014 14:50:23 +1300

Florent,

Where I can I find an algorithm description (or the code) for
skb_get_hash ? I'm curious to know whether it meets the requirements
described in RFC 6437. The algorithm suggested in the appendix of that RFC
is lousy, as shown at https://www.cs.auckland.ac.nz/~brian/flowhashRep.pdf
FNV1a-32 is much better, for example.

Regards
   Brian