IETF Logo Mail Archive

[6lowpan] LoWPAN simple fragment Recovery

Fred Baker <fred@cisco.com> Tue, 16 June 2009 22:52 UTC

Return-Path: <fred@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 0064A28C1F2 for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 15:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.487
X-Spam-Level:
X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 sx31wGQnjMsM for <6lowpan@core3.amsl.com>; Tue, 16 Jun 2009 15:52:16 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 25C513A67BD for <6lowpan@ietf.org>; Tue, 16 Jun 2009 15:52:16 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,232,1243814400"; d="scan'208";a="170525329"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2009 22:52:15 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5GMqFor028921; Tue, 16 Jun 2009 15:52:15 -0700
Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5GMqEcN007895; Tue, 16 Jun 2009 22:52:15 GMT
Message-Id: <D4DFC5FB-2185-40E5-AAA1-7D82422C5DAD@cisco.com>
From: Fred Baker <fred@cisco.com>
To: draft-thubert-6lowpan-simple-fragment-recovery@tools.ietf.org
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 16 Jun 2009 15:52:14 -0700
X-Mailer: Apple Mail (2.935.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=628; t=1245192735; x=1246056735; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20<fred@cisco.com> |Subject:=20LoWPAN=20simple=20fragment=20Recovery |Sender:=20; bh=1ulz38IUPeqQAn2XKUHw/3z9bjR1mAHgRn15uxS+SbU=; b=T3gOOpIkhHKPNZe/67XNRqCrri0Up+rX1Mcbu0WlDOEgaGjeM9gRxR9NTR H0ClPvqMX/STsyZX9F9ep6+8xUwypXqMWZrhVdJ3ZcCcfwozxK5PaPLcZumv H3kY7Y63j7;
Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Mailman-Approved-At: Tue, 23 Jun 2009 09:10:09 -0700
Cc: 6lowpan@ietf.org
Subject: [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: Tue, 16 Jun 2009 22:52:17 -0000

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