Subject: Re: [v6ops] Comments on draft-vasilenko-v6ops-ipv6-oversized-analysis

From: Jen Linkova <[email-masked]>
Date: Mon, 2 Aug 2021 13:13:51 +1000

On Fri, Jul 30, 2021 at 8:40 PM Vasilenko Eduard
<[email-masked]> wrote:
> 1a. It is a very small part of the draft

Hmm..I might need to re-read it then - I got an impression that "1500
bytes buffer" is a key part of the problem statement.
So if the draft is not talking about:
- 1500 bytes buffer
- inserting EHs on the fly (as it's prohibited, and packets shall be
encapsulated instead)

what would remain in the document? More importantly, what would be
specific to IPv6? Many applications set the DF flag for IPv4 now, so
there is not much difference between IPv4 and IPv6 nowadays (I looked
at traffic on my laptop: almost 100% of IPv4 traffic has the DF bit
set).
If anything, IPv4 should be worse, as for IPv4 the minimum MTU a host
can assume is 68 bytes..;)

>because it has the conclusion that the host is far from stress 220B, but after some number of years, it should be revisited. Because if we would see big headers overhead from hosts directly then we should not fully rely on what vendors are doing (big reassemble buffer), but have a more consistent requirement in IPv6 specification. I am sure that IoT devices could not have 64k reassembly buffer:-)

I suspect that the reassembly buffer for those devices would be the
same for IPv4 and IPv6. So the problem wouldn't be IPv6-specific.

> I have seen ECMP: 4*8*16*8*4=2^14 just for LAG then It has additional *16 LSP planes to split fat flows (to improve TE results). It is probably the worst case. It was difficult to troubleshoot - iOAM makes sense.

Oh I've seen a lot of scenarios when the network was getting
dangerously close to exceeding the number of ECMP next hops supported
by hardware. However running that type of network as an overlay on top
of Internet/links with low MTU? Not very popular design, I believe.

> -----Original Message-----
> From: Jen Linkova [mailto:[email-masked]]
> Sent: Friday, July 30, 2021 8:31 AM
> To: Vasilenko Eduard <[email-masked]>; V6 Ops List <[email-masked]>
> Subject: Comments on draft-vasilenko-v6ops-ipv6-oversized-analysis
>
> Hi Eduard,
>
> I'd like to elaborate a bit on my comment I made during the v6ops session today.
>
> 1) RFC8200 defines the minimum value for the reassembly buffer to 1500 bytes. and says: "An upper-layer protocol or application that depends on IPv6 fragmentation to send packets larger than the MTU of a path should
>    not send packets larger than 1500 octets unless it has assurance that
>    the destination is capable of reassembling packets of that larger size."
>
> But it doesn't define what counts as assurance.
> I have reasons to believe that most OSes are capable of reassembling much bigger packets. I tested MacOS 11, Ubuntu and Win10 - all of them are  capable of assembling up to at least 65k bytes. So my first question is: is the issue of "pre-fragmented packet can only be 1500 bytes" observed in real life? Like getting EMSGSIZE on packets just slightly bigger than 1500 bytes?
> (Interestingly enough, the minimum reassembly size for IPv4 MUST be 576, but also "SHOULD be either configurable or indefinite, and SHOULD be greater than or equal to the MTU of the connected network(s)." I'm curious why for IPv6 we just say "1500" but that discussion belongs to 6man).
>
> 2) This is a question which has been bothering me for a while, esp.
> when we discuss draft-ietf-6man-mtu-option...How common are scenarios when two ECMP have different MTUs? The only practical scenario I can imagine is "a network has two ISP uplinks". I'd expect most networks using overlays - especially overlays with IPv6 extension headers - to have unified MTU settings on their links - but it looks like I have a lack of imagination, otherwise we'd not be having this discussion now.
>
> --
> SY, Jen Linkova aka Furry

-- 
SY, Jen Linkova aka Furry

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 2 Aug 2021 11:31:36 +0000

The fact that EHs are added together with additional IPv6 header just exacerbate the MTU problem.
And yes, it is the primary purpose why daft exists because we have more and more headers that many WGs would like to add in transit.
Unfortunately, together with basic IPv6 headers.
Ed/
-----Original Message-----
From: Jen Linkova [mailto:[email-masked]] 
Sent: Monday, August 2, 2021 6:14 AM
To: Vasilenko Eduard <[email-masked]>
Cc: V6 Ops List <[email-masked]>
Subject: Re: Comments on draft-vasilenko-v6ops-ipv6-oversized-analysis

> 1a. It is a very small part of the draft

Hmm..I might need to re-read it then - I got an impression that "1500 bytes buffer" is a key part of the problem statement.
So if the draft is not talking about:
- 1500 bytes buffer
- inserting EHs on the fly (as it's prohibited, and packets shall be encapsulated instead)

what would remain in the document? More importantly, what would be specific to IPv6? Many applications set the DF flag for IPv4 now, so there is not much difference between IPv4 and IPv6 nowadays (I looked at traffic on my laptop: almost 100% of IPv4 traffic has the DF bit set).
If anything, IPv4 should be worse, as for IPv4 the minimum MTU a host can assume is 68 bytes..;)

>because it has the conclusion that the host is far from stress 220B, 
>but after some number of years, it should be revisited. Because if we 
>would see big headers overhead from hosts directly then we should not 
>fully rely on what vendors are doing (big reassemble buffer), but have 
>a more consistent requirement in IPv6 specification. I am sure that IoT 
>devices could not have 64k reassembly buffer:-)

I suspect that the reassembly buffer for those devices would be the same for IPv4 and IPv6. So the problem wouldn't be IPv6-specific.

> I have seen ECMP: 4*8*16*8*4=2^14 just for LAG then It has additional *16 LSP planes to split fat flows (to improve TE results). It is probably the worst case. It was difficult to troubleshoot - iO…

Oh I've seen a lot of scenarios when the network was getting dangerously close to exceeding the number of ECMP next hops supported by hardware. However running that type of network as an overlay on top of Internet/links with low MTU? Not very popular design, I believe.