Yes, the usage of ECMP / LAG is very common. Yes, there is plenty of
data that shows that using just the src and dst IP address in the hash
is NOT good enough. (This does start to get into the quesiton of
whether blindly using the ports is good enough,l but that is the current
practice.)
It is the case that much of the current hardware is built to work around
the common packet cases so as to permit ECMP and LAG. (All? How much?
I do not have the data.)
However, we are seeing a LOT more uses of tunneling. IPSec VPNs are one
use, but they are pretty rare. And they generally have to do enough
processing that the UDP can be done in those cases. So it is.
It should be noted that since tunnels aggregate a lot of sources /
destinations into the tunnel end-point addresses. So if we lose the
inner addresses, and lose the port numbers, we lose a lot of entropy.
In this case, if we could use the flow label, the tunnel device could
creat one that restores much of that entropy. (Not all, by any means.)
But no, GRE does not work. The problem is that the hardware / firmware
is built to look for wpeific things. The more different cases you ahve
to handle in different ways, the harder it gets. So generally, as I
understand it, the ECMP / LAG logic in most devices which do this in
formware / hardware can not use the entropy in the GRE labels.
Also, even if we could use them, GRE labels are not per-flow. they are
typically per underlying user, which at least restores the granularity
of the senders, but not the ports.
Admittedly, part of my original motivation was to find a way to allow
tunnels to be handled without UDP headers so as to not fight about the
UDP header checksum. However, I can not get there in a useful time, so
no, this proposal can not fix any of the immediate issues.
Short of giving up and saying we can never change any of the fields in
the IPv6 header and never fix any of the problems, I am trying to make
this useful for the problems we do have.
Yours,
Joel
On 1/11/2011 9:33 AM, Thomas Narten wrote:
The goal is not to split single flows across multiple links.
Sorry, I know that. Was I that unclear? :-(
But isn't it then a goal (or rather a *requirement*) to split traffic
between a given src/dst pair across multiple links? I.e., there is
enough traffic between a given src/dest pair to justify splitting it
into separate flows for load sharing purposes?
That would seem to be what we are after. I'm trying to understand
exactly which operational scenarios would actually see benefit from
this, and get a sense of how common they are. Are we trying to solve a
common problem, or is are we really solving an edge case?
Which gets us to the problem. In using multiple links (ECMP / LAG) the
routers generally want the finest granularity possible for that
operation.
I understand that they may *want* this. But how bady do they *need*
this?
Is there real data here? Is the current status quo 80% good enough?
95%? or only 30%?
That leads, as you say, to using a hash of the 5-tuple.
However, the 5-tuple is not always available. The simplest case is
tunnels.
Again, how common is this? Is this a 5% problem, or a 50% problem? Or
is this an attempt to prepare for the future, since we don't have
extension headers defined that are a problem today, and too little
traffic is currently encrypted via IPsec...
Unless the tunnel devices add new UDP headers (which is largely
gratuitous and has other problems relative to the IPv6
specifications), the 5-tuple is not visible to the devices
forwarding teh resulting packets. This also leads to IPSec needing
a UDP header. It is also one of the contributors to why using new
extension headers is such a bad idea.
I can see how tunneling would be a problem.
But not for all kinds of tunneling. What about GRE with its key field?
Is this not widely enough used?
Do we have data about what types of tunneling are most common?
Thus, in working at the problem of how to get various kinds of traffic
to be handled for ECMP / LAG, it seemed to many of us that capgturing
the randomness of the port numbers in the flow label would be very
helpful.
In other words, the actual goal here then is to take the data
(entropy) that is currently in the port fields, and put it into the
flow label, and make this happen often enough in practice that routers
can use it *instead of* looking at the port numbers? Is that *really*
what the main goal is here?
(Yes, this assumes that the current hash approach to ECMP / LAG is
reasonable. There is reportedly some question on that, but I take it as
the best practice we have, and therefore worth continuing.)
Right. The question of what makes a good hash is a separate topic.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
