IETF Logo Mail Archive

Re: [6lowpan] LoWPAN simple fragment Recovery

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 17 June 2009 05:57 UTC

Return-Path: <pthubert@cisco.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 4A13C28C133 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 22:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.005
X-Spam-Level:
X-Spam-Status: No, score=-8.005 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 OR-vO2DC3zhK for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 22:57:08 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5D92D3A6DBF for <6lowpan@ietf.org>; Tue, 16 Jun 2009 22:57:08 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,234,1243814400"; d="scan'208";a="177179764"
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 17 Jun 2009 05:57:17 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5H5vGPK014168; Wed, 17 Jun 2009 07:57:16 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5H5vG4v024341; Wed, 17 Jun 2009 05:57:16 GMT
Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 07:57:16 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Jun 2009 07:54:40 +0200
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07A4CC07@xmb-ams-337.emea.cisco.com>
In-Reply-To: <D4DFC5FB-2185-40E5-AAA1-7D82422C5DAD@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: LoWPAN simple fragment Recovery
Thread-Index: Acnu1SoJFct+Zx17RL+xUN/osgTnvQANmXsA
References: <D4DFC5FB-2185-40E5-AAA1-7D82422C5DAD@cisco.com>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "Fred Baker (fred)" <fred@cisco.com>, draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org
X-OriginalArrivalTime: 17 Jun 2009 05:57:16.0322 (UTC) FILETIME=[77AEA820:01C9EF10]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2073; t=1245218236; x=1246082236; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20<pthubert@ci sco.com> |Subject:=20RE=3A=20LoWPAN=20simple=20fragment=20Recovery |Sender:=20; bh=FBVnJUZLALDi23KrriBx/t66owtcCvBUw8pIGbjiPdU=; b=bCuctO/2LCXcqMGr85nmmh90nvC5MsyE/Y8qzZ3snzySmlhWUN2ot35Omu llKkreEOdRiDj+RQBy4op/fmXnf3WxDTY3Z1/w8JbdOyGjrHRaitJ9jBukP2 UJjTXCJ5dM;
Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] LoWPAN simple fragment Recovery
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: Wed, 17 Jun 2009 05:57:09 -0000

Hi Fred:

128 includes a lot of overhead, mostly security; the real usable data
can be in the order of 80 bytes.
In practice RFC 4944 fixes an MTU of 1280 for 802.15.4. So 16 should
still be enough VERY strictly speaking. 

To be considered: some stacks are so constrained that they cannot
receive 2 fragmented packets in parallel so a very large packet will
lock resources for a very long time. Another angle is that ISA100.11a
nodes do not support IP fragments and PMTU discovery on the grounds that
the MTU is 1280.

But I thought that might be a bit short sighted. If we use different
media, with different max frame or security. If 6LoWPAN or an
implementation was to allow up to 1500 or 2048 we'd be in trouble. So I
went for 32 to start with, and I might have overshot. 

The sense of history is that we'll probably not increase MTU for 9K
packets on 802.15.4 and maybe we'll reduce the number of bits in my
fragment recovery header. This is certainly something that will pop up
at the WG to optimize once the group takes the draft aboard. There was a
rough consensus in SFO to accept the draft but the charter does not
really include this work. 

Keep you tuned :)

Pascal

>-----Original Message-----
>From: Fred Baker (fred)
>Sent: mercredi 17 juin 2009 00:52
>To: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org
>Cc: 6lowpan@ietf.org
>Subject: LoWPAN simple fragment Recovery
>
>reading draft-thubert-6lowpan-simple-fragment-recovery-05 and came up
>with a question.
>
>Section 4 indicates that "The recovery mechanism must support highly
>fragmented packets, with a maximum of 32 fragments per packet." I
>agree that 32 128 byte fragments is a lot of fragments, but I'm
>concerned: there is discussion of allowing 9K packets. What happens
>when a 9K packet goes to a sensor? since 9K/128 is on the order of 70,
>you are going to have to reply "packet too big". If that is
>acceptable, why not limit this to 16 fragments, 128*16 being greater
>that 1500 bytes?
>
>Where did "32" come from?
>

v2.23.0 | Report a Bug | By Email