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

[Joseph Touch <[e-mail]>]

> On Mar 22, 2021, at 1:33 PM, Vasilenko Eduard <[e-mail]> wrote:
> 
> Hi Joseph,
> You insist that the second MTU restriction exists for all data plane implementations, just it is not visible and not discussed: neither in any RFC nor in any vendor documentation.

No; it is DEFINED in RFC1122 and noted in both RFC791 and RFC2460 (and 8200). It’s exactly the difference between what can be sent on a path and what is reassembled at an endpoint. Ingress are sources and egresses are sinks; host requirements apply to BOTH.

> But then should be the same effect: fragmentation between MTUs.

They do not.

> I am sure that it is not the case.
> PTB would decrease the only MTU that tunnel has,
> The next oversized packet would get PTB message in the direction of the host.
>  
> The buffer is not relevant for the discussion because data plane firmware just does not have a second MTU. This restriction just does not exist in the real life on the planet Earth.

PTB inside a tunnel needs to update the ingress to change fragment size, because it says “the tunnel path can’t handle the packet size being relayed”, but the path CAN handle the packet if the ingress adjusts. That’s why it is INCORRECT to relay that info to the origin source - PTB inside the tunnel does not mean the tunnel has failed, but rather that it needs to be adjusted.

When the egress cannot reassemble a packet because it is too large, it should send some sort of error back - such as EMTU_R exceeded, but *there is no such ICMP error*. However, IF THERE WERE such a message, then THAT message inside the tunnel should generate a PTB to the origin host. That’s because if you exceed EMTU_R of the tunnel egress, then the source has to send smaller packets - there’s no other way.

In a nutshell, THAT IS WHY THEY ARE DIFFERENT:
	- PTB inside the tunnel means “I’d PREFER a different size, but can still live with this size”
		it cannot be relayed to the origin because there is no meaning that indicates PREFERENCE - only strict capability
	- EMTU_R exceeded inside the tunnel means “I cannot accommodate this size at all”
		which WOULD need to be relayed to the origin source as PTB

The ultimate problem here is that:
	- there aren’t the right ICMP messages to do this correctly
	- there’s no point in creating new ICMP messages to fix the issue, given ICMPs are generally blocked

Joe