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

From: Ole Troan <[email-masked]>
Date: Sun, 29 Jul 2018 13:48:13 +0200

Thanks for writing this down.

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.

Control packets must look just like application packets.
We can argue where TE, TD flags and MTU option should go, but new extension headers and the use of ICMP messages are tricky.
You can argue that new TCP options have issues too. ;-)

(For mechanisms without bi-directional signalling, like IP in IP tunnels, it is possible to do PMTU discovery through one-sided probing.
E.g. tunnel end-point A sends and packet via tunnel end-point B to itself.)

Cheers,
Ole

> On 29 Jun 2018, at 20:33, Ron Bonica <[email-masked]> wrote:
> 
> 
> 
> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Friday, June 29, 2018 2:27 PM
> To: Ron Bonica <[email-masked]>; John Leddy <[email-masked]>
> Subject: New Version Notification for draft-leddy-6man-truncate-04.txt
> 
> 
> A new version of I-D, draft-leddy-6man-truncate-04.txt has been successfully submitted by Ron Bonica and posted to the IETF repository.
> 
> Name:		draft-leddy-6man-truncate
> Revision:	04
> Title:		IPv6 Packet Truncation
> Document date:	2018-06-29
> Group:		Individual Submission
> Pages:		15
> URL:         https://tools.ietf.org/html/draft-leddy-6man-truncate-04
> Status:     https://datatracker.ietf.org/doc/draft-leddy-6man-truncate/
> Htmlized:   https://tools.ietf.org/html/draft-leddy-6man-truncate-04
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-leddy-6man-truncate
> Diff:  https://www.ietf.org/rfcdiff?url2=draft-leddy-6man-truncate-04
> 
> Abstract:
>   This document defines IPv6 packet truncation procedures.  When an
>   IPv6 source node originates a packet, it can mark the packet as being
>   eligible for truncation and forward it towards its destination.  If
>   an intermediate node cannot forward the packet because of an MTU
>   issue, it truncates the packet, marks it as being truncated, and,
>   again, forwards it towards its destination.  When the destination
>   node receives the packet, it detects that it has been truncated and
>   sends an ICMP message to the source node.  The ICMP message contains
>   MTU information that the source node uses to update its Path MTU
>   estimate.
> 
>   The above-mentioned procedures enhance Path MTU Discovery (PMTUD) by
>   eliminating its reliance on the network's ability to deliver ICMP
>   messages from an intermediate node to the source node.  However, the
>   above-mentioned procedures require the network to deliver ICMP
>   messages from the destination node to the source node.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------