Hello, Thomas! On 11.01.11 17:33, "Thomas Narten" <[email protected]> wrote:
>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? IPv4 5-tuples load-balancing is not always working perfectly for everyone. I have encountered lot of occasions where it's far from perfect. Simplest example would be a VPN concentrator on a LAG. IPv6 is not going to be better then IPv4 when it comes to 5-tuples computation. In fact due to many tunnel transition techniques, it will be worse in general. Also, don't forget that extension header structure is more complex and in many cases routers (especially hardware-based) will not be able to look into layer 4 information. > >> 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? Yes, they do. In a perfect world everybody is happily running 100GE everywhere, but it's not happening in real life. People want to keep their current transport for as long as they can. It's not an uncommon request to have more then ten STM-16s bundled and it's a common expectation to have effective throughput of aggregated link to be an exact sum of components. And if you put any "smart" MPLS TE UCMP on top of that, you can get in a real trouble with 5-tuples. > >Is there real data here? Is the current status quo 80% good enough? >95%? or only 30%? I'm not sure what are you proposing to measure... >> 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... Again, 5% of what? Packets traveling in the internet? These drafts try to deal with fundamental load-balancing issue. There is a chance that traffic patterns in 10 years from now will be completely different. Maybe everything will finally collapse inside TCP/80. Maybe everything will be inside ESP. Maybe end-to-end will be reborn. Nobody can tell. But obviously we don't want IPv6 to fail just because of that. Load-balancing is too important to leave it to layer 4. >> 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? No, it is not. >Do we have data about what types of tunneling are most common? ESP is the most common non-UDP and non-TCP tunneling mechanism these days. Nobody can reliably predict how will it change in the future. >> 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? Don't forget that load-balancing is often done by layer-2 devices. You can't expect cheap ASIC-based switches to dig through extension headers and find port numbers or GRE keys. But they definitely can look into statically-placed fixed-length flow label at very low processing cost. >> (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. Load-balancing hashes have traditionally been implementation-specific. Maybe we should leave them this way. > >Thomas >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >[email protected] >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- Best Regards, Yaroslav -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
