IETF Logo Mail Archive

Re: [6lowpan] RFC 4944 fragmentation and future extensions

Jonathan Hui <jhui@archrock.com> Sat, 20 February 2010 18:24 UTC

Return-Path: <jhui@archrock.com>
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED10B28C0FD for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 10:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQpn0Mw-B9z2 for <6lowpan@core3.amsl.com>; Sat, 20 Feb 2010 10:24:44 -0800 (PST)
Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 263123A821E for <6lowpan@ietf.org>; Sat, 20 Feb 2010 10:24:44 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5B518AF913; Sat, 20 Feb 2010 10:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj3evN3RCXzm; Sat, 20 Feb 2010 10:26:30 -0800 (PST)
Received: from [10.0.1.5] (adsl-71-142-67-144.dsl.pltn13.pacbell.net [71.142.67.144]) by mail.sf.archrock.com (Postfix) with ESMTP id 83EC2AF99F; Sat, 20 Feb 2010 10:26:30 -0800 (PST)
Message-Id: <0B6BB048-397D-452D-BF8C-D5239198927C@archrock.com>
From: Jonathan Hui <jhui@archrock.com>
To: Richard Kelsey <richard.kelsey@ember.com>
In-Reply-To: <87pr409d4b.fsf@kelsey-ws.hq.ember.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sat, 20 Feb 2010 10:26:29 -0800
References: <87tythufek.fsf@kelsey-ws.hq.ember.com> <4B7B0875.8060609@exegin.com> <87mxz7visw.fsf@kelsey-ws.hq.ember.com><4B7C454C.2090403@exegin.com> <4B7DAC04.5070109@exegin.com><FE4E6115-66DC-43B6-84D1-ECBBC82A93AD@archrock.com> <87fx4xuy9s.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABAB@XMB-AMS-107.cisco.com> <87eikhux12.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D0149ABFF@XMB-AMS-107.cisco.com> <C84EDB93-2EB2-48BC-9E49-184D6CF14403@archrock.com> <E7625493-244B-47D9-902D-CD6B96944E57@tzi.org> <877hq9ulk5.fsf@kelsey-ws.hq.ember.com> <4B7EE965.3030602@exegin.com> <70063E19-09DC-4F4B-84AC-5A9A4279EC36@tzi.org> <26426FD5-EAD2-4A26-8F94-1B130346F0D2@archrock.com> <87pr409d4b.fsf@kelsey-ws.hq.ember.com>
X-Mailer: Apple Mail (2.936)
Cc: cabo@tzi.org, 6lowpan@ietf.org
Subject: Re: [6lowpan] RFC 4944 fragmentation and future extensions
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Feb 2010 18:24:45 -0000

On Feb 20, 2010, at 6:48 AM, Richard Kelsey wrote:

>> From: Jonathan Hui <jhui@archrock.com>
>> Date: Sat, 20 Feb 2010 00:42:57 -0800
>>
>> On Feb 19, 2010, at 11:19 PM, Carsten Bormann wrote:
>>
>>> I don't think that 4944 specifies anything that lets you have the
>>> compressed header extend beyond the first frame.
>>> I'm not sure we explicitly discussed this, but certainly I didn't
>>> see a need.
>>>
>>> If we now do, I'd like to first learn more about this use case.
>>
>> I'm not convinced of this use case either and I'm fine with limiting
>> use of IPHC/NHC to the first fragment.
>>
>> Richard's future-compatibility case that he spawned this thread with
>> is more important to consider.
>
> The two issues are related.
> [... Richard's explanation of how the issues are related ...]

Yes, I agree they are related.  But I find it more useful to think of  
it as a forward-compatibility issue.  Note that RFC 4944 did not allow  
any kind of forward compatibility.  If you need to insert a routing  
header, the encoding of Section 10 of RFC 4944 would require expansion  
of any compressed UDP/ICMPv6/TCP headers.  Because 6lowpan-hc  
decouples the encoding for each individual header, we now have the  
chance to start considering forward compatibility for higher-layer  
headers.  If we were to continue the limitations implicitly defined by  
RFC 4944, then there would be no fundamental flaws in the  
fragmentation mechanism to talk about.

> The use of the compressed offsets in the fragment headers
> introduces a number of complicated layering issues.  It
> makes fragmentation and compression interdependent.  It
> makes relaying nodes process transport headers.  It
> interacts with the use of routing headers.  What benefits
> does it bring that make it worth all of the headaches?


I think you meant to say "The use of *uncompressed* offsets".  I  
completely agree and I noted the same layering/dependency issues in an  
earlier mail.  Viewing the fragmentation payload as opaque would  
eliminate these dependencies.  Carsten suggested that we could treat  
higher-layer compression as payload of 6lowpan-hc (rather than as a  
part of), but that would eliminate any benefit from using uncompressed  
offsets.

Regardless of what we decide to do with the fragmentation header, I  
would really like to see a clean separation between fragmentation and  
header compression.  Note that saying "compressed offsets/lengths" is  
a bit of a misnomer.  It's better to say that offsets and lengths  
simply reflect the actual payload being fragmented (which may or may  
not use header compression).

--
Jonathan Hui

v2.23.0 | Report a Bug | By Email