Re: [IPv6] FW: New Version Notification for draft-ls-6man-ipcomp-exclude-transport-layer-00.txt

["Shihang(Vincent)" <[e-mail]>]

Hi Nick,
Thanks for your comments. Reply inline.

Best,
Hang Shi
-----Original Message-----
From: Nick Hilliard <[e-mail]> 
Sent: Monday, October 24, 2022 4:28 PM
To: Shihang(Vincent) <[e-mail]>
Cc: [e-mail]
Subject: Re: [IPv6] FW: New Version Notification for draft-ls-6man-ipcomp-exclude-transport-layer-00.txt

Shihang(Vincent) wrote on 24/10/2022 04:51:
> Hi 6MAN,
> I submitted a new draft about extensions to IPComp which compresses IP payload excluding transport layer and handles the out-of-order processing of compressed and un-compressed IP packet.
> 
> Looking forward to your review and comments.

couple of things on this draft:

- it's not clear that there is a need for a transport layer compression mechanism.  Application layer compression has been around for a long time and works well.
[HS] It is not about the transport layer compression. The IPComp(see RFC2713) will compress the IP payload, including the transport layer information. We propose an extension of IPComp to exclude the 4bytes of transport layer header out of the compression range.

- as you identified in the draft, the mechanism proposed in this case will cause breakage:

>    [...]  Therefore, the
>    transport layer information such as source port and destination port
>    is compressed. [...]   If IPComp compressed those
>    transport layer information, the nodes along the packet's delivery
>    path can not obtain the source port and destination port.  Therefore
>    the IPComp is not compatible with the network functions requiring the
>    transport layer information which makes it harder to deploy.

Examples of things which require transport layer information: ECMP/LAG, filtering, control plane protection, etc.  If this information cannot be inspected, then this creates a serious regression for normal network function.

- in some cases, the output of a compression algorithm will be longer than the input. There is no indication in the draft how this would be handled.
[HS] Indeed, the compression algorithm may produce longer result. RFC3173 talks about the problem in section 2.2 and I quote it here:
	" If the total size of a compressed payload and the IPComp header, as
   defined in section 3, is not smaller than the size of the original
   payload, the IP datagram MUST be sent in the original non-compressed
   form.  To clarify: If an IP datagram is sent non-compressed, no
   IPComp header is added to the datagram."

	Basically, if the compression can not produce short packet, the packet is not compressed and no IPComp header is added.
	However, the packet with IPComp header and without IPComp header will go through different process in the receiver end and cause out-of-order. That is why we are proposing add IPComp header even if the packet is sent uncompressed.


Nick