Re: [6lowpan] Call for working group adoption (Re: making progress on fragmentation)

Carsten Bormann <cabo@tzi.org> Tue, 18 August 2009 16:27 UTC

Return-Path: <cabo@tzi.org>
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 C1EFF3A6E7E for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 09:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.953
X-Spam-Level:
X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tjT34Cun0sdJ for <6lowpan@core3.amsl.com>; Tue, 18 Aug 2009 09:27:27 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 855AD3A683F for <6lowpan@ietf.org>; Tue, 18 Aug 2009 09:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n7IGRNKK005082 for <6lowpan@ietf.org>; Tue, 18 Aug 2009 18:27:23 +0200 (CEST)
Received: from [192.168.217.101] (p5489F20B.dip.t-dialin.net [84.137.242.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id DDFD5BD07; Tue, 18 Aug 2009 18:27:22 +0200 (CEST)
Message-Id: <0A5E490A-5E03-4741-8F34-F001EABCE91D@tzi.org>
From: Carsten Bormann <cabo@tzi.org>
To: 6lowpan <6lowpan@ietf.org>
In-Reply-To: <0C6EA69F-2455-4A8F-96BB-596576A790FB@cisco.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: Tue, 18 Aug 2009 18:27:21 +0200
References: <87ljlh2tpx.fsf@kelsey-ws.hq.ember.com> <4186F14A-435F-4C74-9D31-31BF03A6C1A2@tzi.org> <0C6EA69F-2455-4A8F-96BB-596576A790FB@cisco.com>
X-Mailer: Apple Mail (2.936)
Subject: Re: [6lowpan] Call for working group adoption (Re: making progress on fragmentation)
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: Tue, 18 Aug 2009 16:27:27 -0000

On Aug 18, 2009, at 15:37, Ralph Droms wrote:

> does anyone have empirical evidence about the impact of fragment  
> loss in 802.15.4 networks that would motivate the need for reliable  
> fragment delivery?

(no WG chair hat:)

I can't answer that question.

But it is important to describe the applicability of http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-06 
  some more.

As it stands, the draft addresses the mesh-under case.  There is  
little gain for the hop-by-hop fragmentation/reassembly implied by  
route-over; it is also not clear how to apply the draft to the route- 
over fragmentation optimization I described in the other sub-thread  
(who would send the FRACK?).

We do have "fragment recovery" in 4944 in the sense that it is (lower- 
case) recommended to use 802.15.4's link-layer ACK to increase the  
reliability of each (L2) hop (4944, Section 2, first paragraph).

What we don't have is recovery on the whole L2 path from the  
fragmenting L3/L2 boundary (mesh-under ingress, MUI) to the  
reassembling L2/L3 boundary (mesh-under egress, MUE).  The argument I  
have understood for the draft is that there may be (MU) route changes  
(possibly including MU multipath routing) between MUI and MUE during  
transmission of the fragments of a single (larger) packet, causing  
some parts to be lost even with good use of per-hop acknowledgements.

A 1280 byte packet will take some 40 ms of pure airtime on 2.4 GHz or  
some 500 ms on .868 GHz.  Multiply this by a realistic media sharing  
multiplier, and there does appear some opportunity for radio  
characteristics to change during that time.  But that is just a hunch,  
and some numbers from a real-life network would indeed help.

For now, my (WG member) answer to the WG chair's question whether we  
should adopt that draft is a luke-warm "I wouldn't mind".

Gruesse, Carsten