Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?

From: Xuxiaohu <[email-masked]>
Date: Mon, 4 May 2015 02:40:07 +0000

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, April 30, 2015 10:22 PM
> To: Xuxiaohu; Templin, Fred L; Lucy yong; Tom Herbert
> Cc: [email-masked]
> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?
> 
> 
> 
> On 4/29/2015 8:01 PM, Xuxiaohu wrote:
> > Hi Templin,
> ...
> >> Existing tunnel protocols (IP*-in-IP*) are deficient in not providing
> >> a tunnel fragmentation mechanism per Section 3.1.7 of RFC2764.
> >
> > You may have noticed a fact that most modern routers and switches have
> > been capable of processing jumbo frames for a long while. In other
> > words, fragmentation could be completed avoided in most modern
> > networks.
> 
> Jumbo frames are just a larger maximum frame size. Let's say that size is N.
> 
> We're talking about IP-in-IP, IP-in-UDP-in-IP, IP-in-GRE-in-IP, etc. In all cases, you
> have:
> 
> 	N inside N+header

Assume N is equal to 8000, since the max size of the original IP packet is 1500, isn't it (i.e., 8000-1500) large enough to hold additional encapsulation headers?

Best regards,
Xiaohu

> Unless the headers are 0 bytes long, the encapsulated result is always larger than
> the interior contents.
> 
> I.e., if N is your limit, you've now exceeded it. The consequence is that:
> 
> 	any protocol that has non-zero headers and a packet maximum
> 	always needs fragmentation to be encapsulated in itself
> 
> > Even in the sparse network environments where fragmentation is still
> > unavoidable, the default configuration which have been widely
> > supported by most vendors (see
> > https://tools.ietf.org/html/draft-ietf-intarea-gre-mtu-03#page-4)
> > should be enough in most cases. That's the reason why that's
> > implemented by many vendors as the DEFAULT configuration, IMHO.
> 
> It's the default because it maximizes router vendor profit and/or reduced router
> vendor cost, not because it maximizes network flexibility or capability.
> 
> > BTW,
> > it's preferable to avoid reassembling fragments at the tunnel egress
> > due to the negative impact on the forwarding performance, AFAIK.
> 
> It is inherently unavoidable for IPv4 packets with DF=1 or all IPv6 packets.
> 
> > As
> > such, it's not recommended to perform fragmentation on the tunnel
> > layer and the outer IP layer.
> 
> It's provably required for IPv4 DF=1 and IPv6.
> 
> That's why we're trying to address it.
> 
> Joe

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 4 May 2015 02:53:33 +0000

> It's provably required for IPv4 DF=1 and IPv6.

If the IPv4 packets with DF=1 and IPv6 packets are transported over Ethernet, do you still want the Ethernet layer to do fragmentation?

Best regards,
Xiaohu

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 May 2015 09:02:26 -0700

On 5/3/2015 7:40 PM, Xuxiaohu wrote:
> Assume N is equal to 8000, since the max size of the original IP
> packet is 1500, isn't it (i.e., 8000-1500) large enough to hold
> additional encapsulation headers?

That depends on how many encapsulation headers there are. Yes, it's
somewhat absurd to expect 6500 bytes of additional header, so that will
probably fit.

But that's not the case with IPv6 in IPv6; the largest payload is 1240,
but the MTU is 1280.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 04 May 2015 09:05:55 -0700

On 5/3/2015 7:53 PM, Xuxiaohu wrote:
> If the IPv4 packets with DF=1 and IPv6 packets are transported over
> Ethernet, do you still want the Ethernet layer to do fragmentation?

The proof is for IP in anything that eventually goes over IP again.

If you put IP in Ethernet and then put that pack in IP (e.g., via PPP,
EtherIP, or GRE), then the tunnel will need to support fragmentation.

The question is "what layer provides the tunnel". If you treat the
entire set of headers of encapsulation as a set, you can use any layer
in that set you want. If you treat UDP as the sole controllable
encapsulation layer, then you need to support fragmentation there.

The ONLY reason IP doesn't require fragmentation over Ethernet is
because the IP layer directly above Ethernet has an MTU of 1280 (for
IPv6) or 68 (for IPv4) and Ethernet supports an MTU of 1500.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 May 2015 16:10:57 +0000

> Sent: Monday, May 04, 2015 9:06 AM

That, plus we are a long way off from seeing 8K everywhere. Go
to most end user devices, and you will still see 1500. I suspect the
same is true for most networking gear near the edges of the
network.

Thanks - Fred
[email-masked]