Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt - ROHC

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 10 February 2021 12:32 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1A53A0E49 for <tsvwg@ietfa.amsl.com>; Wed, 10 Feb 2021 04:32:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-ngDK140J2G for <tsvwg@ietfa.amsl.com>; Wed, 10 Feb 2021 04:31:59 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FD3A0E4A for <tsvwg@ietf.org>; Wed, 10 Feb 2021 04:31:59 -0800 (PST)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4C3451B00055; Wed, 10 Feb 2021 12:31:53 +0000 (GMT)
To: Carsten Bormann <cabo@tzi.org>, Joseph Touch <touch@strayalpha.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>
References: <160634937123.31668.16222629354118891810@ietfa.amsl.com> <014545D8-D549-4FFF-AF44-64975BA5DB09@strayalpha.com> <31945817-EA0C-416D-B002-EF7A2477654A@tzi.org>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <e39f6bd8-7456-617a-f763-515d1ad53c12@erg.abdn.ac.uk>
Date: Wed, 10 Feb 2021 12:31:52 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <31945817-EA0C-416D-B002-EF7A2477654A@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BlTilMnE9QPUxzISuofczMI8d6Y>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-09.txt - ROHC
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 12:32:02 -0000

Carsten,

I'd like to see if we can find suitable text for the discussion of ROHC 
within the UDP-Options draft.

My own understanding is also that ROHC-compressed UDP packets need to 
match the profile for UDP defined in RFC3095, and that use of 
UDP-Options would result in a packet that can't compressed by the 
current profile - and hence would be sent uncompressed. If I understand 
correctly, this seems worth recording. However the current ID text goes 
further than this, and proposes an update.

Would you like to propose some alternate text for the WG to discuss?

Gorry

On 18/12/2020 14:17, Carsten Bormann wrote:
> On 2020-11-26, at 01:14, Joseph Touch <touch@strayalpha.com> wrote:
>> 	• This doc now updates ROHC 3095 too
>> 		• puts it in line with more recent header compression standards that we caught
>> 		• UDP header compression should ever have assumed that UDP Length is implicit based on IP length
> Specifically, the draft now says:
>
>     This document hereby deprecates the requirement asserted in the UDP
>     profile for Robust Header Compression (ROHC)[RFC3095], noted here:
>
>        "The Length field of the UDP header MUST match the Length
>         field(s) of the preceding subheaders, i.e., there must not
>         be any padding after the UDP payload that is covered by the
>         IP Length.”
>
> This change is highly confused.
>
> You indeed cannot initialize an IR header chain from from a UDP packet where this does not match.  So you would send that uncompressed.  If this MUST were changed, the receiver no longer would be able what length to put into decompressed UDP packets.
>
> Somehow, I feel like responding to an errata report that needs to be rejected…
>
> Grüße, Carsten