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

From: Tom Jones <[email-masked]>
Date: Mon, 9 Jul 2018 13:58:02 +0100

...snip...
> > 3.
> > 
> >           0                   1                   2
> >           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> >          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >          |  Option Type  |  Opt Data Len |T|D|R| Reserved|
> >          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >                                  Figure 2
> > 
> > TCP does not carry a length field in its header, instead it uses the total length
> > field in IPv4 and the payload length in IPv6, modifying this value may make it
> > difficult or impossible for the receiving TCP to find the intended end of
> > segment.  This option needs to carry enough information to reproduce the
> > original payload length field.
> > 
> > I suggest adding the original payload length to the option, like so:
> > 
> >  0                   1                   2                   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 0
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +-+-+-+-+
> > |  Option Type  |  Opt Data Len |T|D|R| Reserved|   Original Payload Length
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> > +-+-+-+-+
> > 
> >                              Figure 2
> > 
> > This will require increasing the option length from 1 to 3.
> > 
> 
> Does TCP need to know the Original Payload Length? What would it do with this information if it had it?
> 
> I suspect that there is a good use for this data, but I am curious to know what it is.
> 

TCP needs to be able to reconstruct the segment length from the ip
payload length, it does not carry a segment length field itself. If we
are going to allow delivery of truncated packets, TCP needs to be able
to find the original segment size. 

In addition, if we use truncate to add padding for pmtud probes we need
to know how much padding was added for the probe so we can strip it off
and get the original packet back.

- [tj]

---

From: Joe Touch <[email-masked]>
Date: Mon, 9 Jul 2018 07:00:36 -0700

> to find the original segment size.

This restores the need but still doesn’t explain why TCP has that need.

Remember that the data in these packets should be discarded anyway, so what would TCP do with this info?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 9 Jul 2018 07:01:20 -0700

> On Jul 9, 2018, at 7:00 AM, Joe Touch <[email-masked]> wrote:
> 
> 
> 
> This restores

Restates.  

> the need but still doesn’t explain why TCP has that need.
>

---

From: Tom Jones <[email-masked]>
Date: Mon, 9 Jul 2018 15:14:12 +0100

> what would TCP do with this info?

Okay I think I understand.

I agree, if truncated packets are always discarded at the end host then
this information is not worth carrying. 

I think there is a powerful mechanism here to do path mtu probing for
TCP:
        - Create an IP datagram of known good pmtu size
        - set the truncate option
        - add padding. 

If the path cannot pass this datagram it will truncate removing the
padding, but leaving the original datagram. This original datagram could
be passed up the stack, really it is as if we only sent the good small
datagram.

On supported paths, ptmu probing could be done without risking a loss in
the tcp congestion controller.

For this to be possible the truncate option needs to indicate how large
the original (before padding) ip datagram was.

- [tj]

---

From: Joe Touch <[email-masked]>
Date: Mon, 09 Jul 2018 08:17:08 -0700

> to find the original segment size.

This restores the need but still doesn't explain why TCP has that need.

Remember that the data in these packets should be discarded anyway, so
what would TCP do with this info? 
Okay I think I understand.

There is no current TCP option for padding, so you'd need to add a new
TCP option for that (that might confuse implementations, including
middle boxes). 

Joe

---

From: Ron Bonica <[email-masked]>
Date: Mon, 9 Jul 2018 20:33:03 +0000

Hi Tom,

I will wait for you and Joe to converge before changing the draft. However, if you decide that you need to know the pre-truncation payload length, I can do the following:

- Add a 16-bit field to both the Truncation Eligible and Truncated Packed options
- On the Truncation Eligible, the value of this field is always zero
- When an intermediate node cannot forward a packet that is eligible for truncation due to an MTU issue
	- Overwrite the Truncation Eligible option with a Truncated Packet option
	- Copy the Payload Length from the IPv6 header to the new field in the Truncated Packet option
	- Truncate the packet
	- Update the Payload Length field in the IPv6 header
	- Forward the packet towards the destination.

                                                               Ron

> -----Original Message-----
> From: Tom Jones <[email-masked]>
> Sent: Monday, July 9, 2018 8:58 AM
> To: Ron Bonica <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tsvwg] FW: New Version Notification for draft-leddy-6man-
> truncate-03.txt
> 
> 
> ...snip...
> > > 3.
> > >
> > >           0                   1                   2
> > > TCP does not carry a length field in its header, instead it uses the
> > > total length field in IPv4 and the payload length in IPv6, modifying
> > > this value may make it difficult or impossible for the receiving TCP
> > > to find the intended end of segment.  This option needs to carry
> > > enough information to reproduce the original payload length field.
> > >
> TCP needs to be able to reconstruct the segment length from the ip payload
> length, it does not carry a segment length field itself. If we are going to allow
> delivery of truncated packets, TCP needs to be able to find the original
> segment size.
> 
> In addition, if we use truncate to add padding for pmtud probes we need to
> know how much padding was added for the probe so we can strip it off and
> get the original packet back.
> 
> - [tj]