Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling

From: [email-masked] (Noel Chiappa)
Date: Tue, 15 Sep 2009 12:36:04 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    >> It may be that there's just no choice for IPv6 that works for all
    >> parties (ISPs, routers, hosts).

    > I actually think of the parties as ISPs, higher-end routers and
    > lower-end routers.

Well, "lower-end routers" and "hosts" to me are, in these circumstances,
almost the same thing; they run, as you say, commodity or mostly-commodity
hardware, and the software base is usually 'bought-in' software. It's
precisely because most of the kit is provided from elsewhere, in both
cases, that they have an issue.

    > My understanding of the ISP requirements is that LISP has to work
    > with LAG/ECMP equipment, not (specifically) that we have to use UDP.
    > Is that correct?

Yes, as best I understand it. The high-level requirement from the large users
who are interested in deploying it (not just ISPs, because large congent
providers often have the same issues, I gather) is that the load can be
spread, _while keeping individual traffic streams in order_.

(I.e. no spreading the packets from a single TCP connection, etc, over
multiple paths; making sure this constraint doesn't get violated as a
result of steps taken during LISP encapsulation is the reason for some of
the encapsulation field-setting algorithms. And apologies if you already]
understood that - I occasionally forget it myself.)

Since deployed stuff - which includes core routers in the main fabric of
the Internet, which LISP is intended to leave untouched - only provide
this capability for UDP and TCP (shudder), the choices are pretty limited.

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 15 Sep 2009 13:06:07 -0400

> understood that - I occasionally forget it myself.)

Right.  We determine the UDP source port from a hash of the five-tuple  
(two IP addresses, IP protocol/next header, and two TCP/UDP ports) in  
the packet that is being encapsulated.  So, the UDP port serves as a  
flow label, of sorts.  This works for LAG/ECMP equipment that load  
balances based on the five-tuple of the outer header.
> this capability for UDP and TCP (shudder), the choices are pretty  

Sort of...

It is my understanding that the deployed LAG/ECMP equipment that  
parses on the five-tuple described above will fall back to a three- 
tuple (2 IP addresses and IP protocol/next header) when the protocol  
in use is not UDP or TCP.  So, if we did a LISP-in-IP encapsulation  
and varied the IID of the source IP address based on a hash of the  
original packets' five-tuple, we would get the same load balancing  
effect as varying the UDP source port.  Is that correct?

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Sep 2009 12:10:11 -0700

> effect as varying the UDP source port.  Is that correct?

Most cisco equipment falls back to (source, dest) when protocol is not  
TCP and UDP. Which is not really good because it causes TCP packet  
drops when UDP is blasting.

Dino

---

From: Sam Hartman <[email-masked]>
Date: Tue, 15 Sep 2009 16:29:04 -0400

>>>>> "Dino" == Dino Farinacci <[email-masked]> writes:

    Dino> Most cisco equipment falls back to (source, dest) when
    Dino> protocol is not TCP and UDP. Which is not really good
    Dino> because it causes TCP packet drops when UDP is blasting.

Dino, I really hate to be sending more messages to this thread.
However I'm confused about what you're saying above.

I don't understand how the second part of your statement (tcp loss)
follows from the first (two-tuple).

---

From: John Zwiebel <[email-masked]>
Date: Tue, 15 Sep 2009 10:39:59 -1000

On Sep 15, 2009, at 10:29 AM, Sam Hartman wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

The packets are not spread over the LAG but only over one link
One link gets full, the other can be empty.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 Sep 2009 14:05:25 -0700

> follows from the first (two-tuple).

No prob. Let me explain.

If TCP and UDP are encapsulated in IPsec or GRE, then TCP suffers  
because it is competing with UDP for bandwidth and output queue  
resources for a member of a LAG.

Having a 3-tuple hash would work as Margaret suggests, if it was  
(outer-source,outer-dest,inner-protocol) then you could have TCP and  
UDP possibly hash differently.

Dino