Re: [v6ops] Proxy function for PTB messages on the tunnel end

[Joseph Touch <[e-mail]>]

Hi, Eduard,

> On Mar 22, 2021, at 4:28 AM, Vasilenko Eduard <[e-mail]> wrote:
> 
> Hi Joseph,
> I probably need to tell why I like the initial RFC 2473: it requests PTB “proxy” functionality from tunnel ends. (well, it is not called “proxy” inside RFC 2473 – it just discusses how to re-create PTB from PTB on the tunnel end). This initial architecture decision of IPv6 (to inform the real traffic source) is the basement for PMTU to work. It is better to fix it, not to invent some other patches for MTU discovery.

You should review the discussions on why PMTUD does not work in the Internet. That’s why we have PLPMTUD.

So I’m not clear that fixing PMTUD is worth any effort at all. 

However...

> Longer explanation:
> If PTB message would be created on the tunnel path – it would easily inform “tunnel end” of Oversized packet – tunnel MTU could be decreased.

Path MTU ICMP errors indicate when a packet CANNOT TRAVERSE A LINK. 

As a *link*, a tunnel’s MTU is its EMTU_R. It cannot be its EMTU_S or path MTU. If it were, then there could never be IPv6-in-IPv6 because no IPv6-in-IPv6 tunnel can relay internal segments of 1280B without ingress source fragmentation. 

Is that what you want? 

> It is already a solution because the next Oversized packet from the source would get PTB response from the tunnel end itself – the source would get PTB after the second oversized packet.
> But it was better to inform the real traffic source after 1st Oversized packet. Hence, PTB proxy on the tunnel end is better.
>  
> I am not ready to discuss all corrections of draft-ietf-intarea-tunnels section 5.2 to RFC 2473 – they do not have relationships to PMTUD.
> Except one that would lead to the massive fragmentation that I would discuss in the next email.
> Eduard
> From: Joseph Touch [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Sunday, March 21, 2021 7:23 PM
> To: Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]>; int-area <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [v6ops] draft-vasilenko-v6ops-ipv6-oversized-analysis-00
>  
> Hi, all,
>  
> Spoiler alert if you don’t want to read the whole post:
>             - draft-vasilenko makes erroneous claims as to the content in draft-tunnels
>             - draft-tunnels and draft-vasilenko are consistent (once the latter is corrected) in their mutual conclusions
>                         - draft-tunnels on the need for fragmentation over finite MTU paths
>                         - draft-vasilenko in encouraging increases in those finite MTUs
>  
> Joe
>  
> ---
>  
> First, draft-ietf-intarea-tunnels is discussed on the int-area list; after review of the information below, if you still believe there are issues to be addressed in that doc, you should post them there.
>  
> The technical errors in RFC2473 have been indicated in that document since draft-ietf-intarea-tunnels-01, posted in July 2015. They remain accurate, IMO. 
>  
> Note that I ceased performing in-place updates of that document because of *lack of active discussion* and because in-place updates are a waste of my time.
>  
> I am glad to see someone in IPv6 interested now, and would be glad to update my draft as needed.
>  
> FWIW, having read your doc, here are its errors in misstating the content of my draft:
>  
> - your doc mistakenly assumes that mine requires IPv6 hosts to send 1500B packets if they can, even if tunnels are on the path
>             as with any IPv6 path, the source should send fragments no larger than the entire path can transit, whose reassembled size is no larger than the receiver can reassemble
>             those original fragments are what enter the on-path tunnels, so they should be no larger than the tunnel egress can fragment
>             and those original fragments would be encapsulated and then source fragmented by the tunnel according to the same (recursive) policy
>  
> - nothing in draft-tunnels assumes ICMP PTB cannot adjust these sizes or that the tunnel cannot use PLPMTUD
>             see sec 4.3.1 of v10
>  
> - draft-tunnels does not “introduce” a new variable called tunnel MTU; I introduced the terminology, but the concept is as old as tunnels
>             I coined that term to refer to the MTU across the tunnel with reassembly at egress (which already exists), as different from the MTU between ingress and egress (which I call tunnel MAP)
>             sec 4.2.3 of v10 doesn’t claim this value cannot be set; in explains that PMTUD has no role in discovering its value:
>           Note, however, that PMTUD never discovers
>           EMTU_R that is larger than the required minimum; that information is
>           available to some upper layer protocols, such as TCP [RFC1122 <https://tools.ietf.org/html/rfc1122>], but
>           cannot be determined at the IP layer.
>             I never said it cannot be discovered
>                         it should be (e.g., by a tunnel configuration protocol)
>                         note that there are no current protocols that do this, even without tunnels (i.e., discover larger EMTU_R)
>                         I can add that point as clarification
>  
> - draft-tunnels does not increase IPv6 fragmentation
>             please indicate why you believe it would (notably here "a considerable increase in fragmentation is proposed for the reasons of academic purity”)
>  
> - draft-tunnels does not claim fragmentation is the only solution to oversize packets
>             it addresses how and where to handle tunnels in the presence of packet limits, of which path MTU is only one
>  
> - ICMP PTB is not a solution out to the origin source
>             that would potentially drop the IPv6 path MTU below 1280, given enough tunnel overhead (or layers thereof), a violation of IPv6
>             so yes, in that case, the ONLY solution that preserves IPv6 in the presence of tunnels with that much overhead would be ingress source fragmentation
>  
> - sec 3.3 of my doc DOES allow ICMPs to be relayed back to the source
>             it merely states that they should be generated when a packet too large to ingress arrives, 
>             NOT when an internal tunnel ICMP is received by the ingress
>  
>             the point is that the origin source sees the ingress as a router on the path,
>             so it should get ICMPs from that router only when packets arrive at that router, not when its tunnel fails downstream
>  
>             this makes ICMP relay *easier* and more reliable to implement; the ingress gets tunnel ICMPs to learn the tunnel’s effective link MTU,
>             then uses that link MTU to send ICMPs back
>  
>             yes, this is to allow the tunnel to act as the link *that it is*, but it does not prohibit ICMP info from flowing back to the source
>  
> And finally:
>  
> - nobody is claiming we shouldn’t increase link MTU
>             draft-tunnels would still be relevant, no matter how large the MTU is, for the reasons I state in that doc
>  
> One other observation:
>  
> - your statistics for fragment drops apply only when the fragment is visible to the IP layer
>             there are intermediate layers that hide fragmentation for exactly this reason, e.g., UDP tunnels, GRE, etc.
>  
> ---
> 
> 
> On Mar 21, 2021, at 1:59 AM, Vasilenko Eduard <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Dear Experts,
> I have seen many recent activities in IETF related to MTU problems. Well, maybe not so active as some others, but active anyway. Many other active drafts are evaluated in this draft.
> I had an idea what is the right way to solve problems in this area, but after the research, it has been found that foundations were discussed in RFC 2473 (Dec 1998). Just people have forgotten about it.
> We have discussed it with co-authors and we have decided that it make sense to publish the research because it looks at the problem in a systematic approach.
> 
> The one thing that is alarming in this research: draft-ietf-intarea-tunnels is pushing for much more fragmentation for pure Academic reasons. This draft is already referenced by many other documents.
> I believe that not many people have spent enough time to understand it's complexity to reveal the truth: the majority of the IPv6 traffic would be fragmented if it would follow draft-ietf-intarea-tunnels.
> 
> Thanks to everybody who would spend enough time to produce comments.
> Eduard
> -----Original Message-----
> From: [e-mail] <mailto:[e-mail]> [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Friday, March 19, 2021 11:07 PM
> To: Dmitriy Khaustov <[e-mail] <mailto:[e-mail]>>; Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>; Vasilenko Eduard <[e-mail] <mailto:[e-mail]>>; Xipengxiao <[e-mail] <mailto:[e-mail]>>; Xipengxiao <[e-mail] <mailto:[e-mail]>>
> Subject: New Version Notification for draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> 
> 
> A new version of I-D, draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> has been successfully submitted by Eduard Vasilenko and posted to the IETF repository.
> 
> Name:             draft-vasilenko-v6ops-ipv6-oversized-analysis
> Revision:         00
> Title:               IPv6 Oversized Packets Analysis
> Document date:          2021-03-19
> Group:             Individual Submission
> Pages:              19
> URL:            https://www.ietf.org/archive/id/draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt <https://www.ietf.org/archive/id/draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-vasilenko-v6ops-ipv6-oversized-analysis/ <https://datatracker.ietf.org/doc/draft-vasilenko-v6ops-ipv6-oversized-analysis/>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-vasilenko-v6ops-ipv6-oversized-analysis <https://datatracker.ietf.org/doc/html/draft-vasilenko-v6ops-ipv6-oversized-analysis>
> Htmlized:       https://tools.ietf.org/html/draft-vasilenko-v6ops-ipv6-oversized-analysis-00 <https://tools.ietf.org/html/draft-vasilenko-v6ops-ipv6-oversized-analysis-00>
> 
> 
> Abstract:
>   The IETF has many new initiatives relying on IPv6 Enhanced Headers
>   added in transit: SRv6, SFC, BIERv6, iOAM. Additionally, some recent
>   developments are overlays (SRv6, VxLAN) over IPv6. It could create
>   oversized packets that need to be dealt with. This document analyzes
>   available standards for the resolution of oversized packet drops.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>