Subject: Re: [tsvwg] New Version Notification for draft-leddy-6man-truncate-04.txt

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Oct 2018 12:23:04 +0200 (CEST)

On Sun, 29 Jul 2018, Ole Troan wrote:

> For a redesigned path MTU discovery mechanism, I would liked it to work 
> something like the following. Using TCP as an example.
>
> Host A sends a TCP SYN to host B, with the Truncation Eligible (TE) set, and the packet padded out to the outgoing interface MTU.
> Routers on the path truncate the packet as needed and set the Truncated done bit (TD). Host B sends a syn ack back to host A that is padded out to the maximum interface MTU, with the received packet length stored in a TCP option.
> Host A receives the packet notes the path MTU, and in it's ack includes the received packet length as an MTU option to host B.
>
> Full bi-directional path mtu discovery done as part of the TCP hand-shake.

I like this proposal. However, wouldn't that mean that the end system also 
understands how long the unpadded payload is, to understand if it gets the 
entire one (and then doesn't discard it)? Also, if things along the way do 
not support this draft then you'd get a lot of potential timeouts while 
you probe for the MTU? For connections that might never have hit the PMTUD 
limit (only used small packets because of small messages), they'd fare 
worse by this approach.

Also, have we heard from the hardware guys, the people making the core 
router NPUs that would need to do what we're discussing? Do they see a 
problem with this approach?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 18 Oct 2018 21:48:07 +0000

> From: Mikael Abrahamsson <[email-masked]>
> Sent: Thursday, October 18, 2018 6:23 AM
> 
> > For a redesigned path MTU discovery mechanism, I would liked it to
> > work something like the following. Using TCP as an example.
> >
> > Host A sends a TCP SYN to host B, with the Truncation Eligible (TE) set, and
> the packet padded out to the outgoing interface MTU.
> > Routers on the path truncate the packet as needed and set the Truncated
> done bit (TD). Host B sends a syn ack back to host A that is padded out to the
> maximum interface MTU, with the received packet length stored in a TCP
> option.
> > Host A receives the packet notes the path MTU, and in it's ack includes the
> received packet length as an MTU option to host B.
> >
> entire one (and then doesn't discard it)? Also, if things along the way do not
> support this draft then you'd get a lot of potential timeouts while you probe
> for the MTU?

I also would not want to play such games as padding TCP SYN and TCP SYN/ACK packets.  There are too many middleboxes that may examine the packets and chose to drop them, interfering with the handshake.  As Mikael points out, even the receiver may drop the packet as invalid, unless it is aware of what's going on.  I'd leave TCP handshake as plain as it can be and perform PMTUD activities using subsequent packets that will not have a catastrophic effect if silently dropped.

As for the draft itself (while staying within TCP specs), no router on path should be examining destination options while forwarding packets (rfc2460/8200 and this ID stipulate this).  It is only when a router runs into an MTU problem (and implements this ID) that it would look for Truncation Eligible (TE) option.

That said, some middleboxes may choose to examine all options and drop packets featuring unknown ones (despite of what rfc2460/8200 say).  Hence, sending TE option can be managed similarly to sending ECN.

> For connections that might never have hit the PMTUD limit (only used small
> packets because of small messages), they'd fare worse by this approach.

TE option would likely only be set for packets that act as PMTU probes.  An endpoint that does not need to send large packets is not likely to perform PMTUD.

> problem with this approach?

There are no requirements on router NPUs in this approach.  When a packet cannot be forwarded due to MTU, it is handled by the slow path (router CPU), and NPU is not involved.

- Igor