From nobody Wed Feb 10 08:13:32 2021 Return-Path: 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 96ABC3A0E8E for ; Wed, 10 Feb 2021 08:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Qbg_Fd1y3k65 for ; Wed, 10 Feb 2021 08:13:25 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A833A0EDF for ; Wed, 10 Feb 2021 08:13:25 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DbPv81FZ8zyV5; Wed, 10 Feb 2021 17:13:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <9089311D-3EE3-4127-9FCF-124B78692900@strayalpha.com> Date: Wed, 10 Feb 2021 17:13:23 +0100 Cc: Gorry Fairhurst , tsvwg IETF list X-Mao-Original-Outgoing-Id: 634666403.430918-1ae2a49344b3de86c4badbbd00057e33 Content-Transfer-Encoding: quoted-printable Message-Id: References: <160634937123.31668.16222629354118891810@ietfa.amsl.com> <014545D8-D549-4FFF-AF44-64975BA5DB09@strayalpha.com> <31945817-EA0C-416D-B002-EF7A2477654A@tzi.org> <9089311D-3EE3-4127-9FCF-124B78692900@strayalpha.com> To: Joseph Touch X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2021 16:13:31 -0000 Note that with ROHCv2, the Protocol is STATIC-DEF, so you should be able = to set up an instance of the UDP-Lite profiles (0x107 and 0x108) in the = presence of UDP-Options. I think. Gr=C3=BC=C3=9Fe, Carsten > On 2021-02-10, at 16:50, Joseph Touch wrote: >=20 > Hi, Gorry, >=20 > I think the discussion we had back in Dec concluded that =E2=80=9Cyou = can only USE a profile if it applies=E2=80=9D, so that would mean a = correct ROHC implementation would need to *check* whether the UDP Length = was consistent with the IP length and only compress using the given = profile if that were true. >=20 > So the UDP options doc does not need to update ROHC, but I think we do = need to make this clear in our doc. >=20 > Joe >=20 >> On Feb 10, 2021, at 4:31 AM, Gorry Fairhurst = wrote: >>=20 >> Carsten, >>=20 >> I'd like to see if we can find suitable text for the discussion of = ROHC within the UDP-Options draft. >>=20 >> 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. >>=20 >> Would you like to propose some alternate text for the WG to discuss? >>=20 >> Gorry >>=20 >> On 18/12/2020 14:17, Carsten Bormann wrote: >>> On 2020-11-26, at 01:14, Joseph Touch wrote: >>>> =E2=80=A2 This doc now updates ROHC 3095 too >>>> =E2=80=A2 puts it in line with more recent header = compression standards that we caught >>>> =E2=80=A2 UDP header compression should ever have = assumed that UDP Length is implicit based on IP length >>> Specifically, the draft now says: >>>=20 >>> This document hereby deprecates the requirement asserted in the = UDP >>> profile for Robust Header Compression (ROHC)[RFC3095], noted here: >>>=20 >>> "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.=E2=80=9D >>>=20 >>> This change is highly confused. >>>=20 >>> 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. >>>=20 >>> Somehow, I feel like responding to an errata report that needs to be = rejected=E2=80=A6 >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >=20