IETF Logo Mail Archive

Re: [6lowpan] piggybacked fragment ACKs

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 25 June 2009 07:01 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 A62CA3A6D18 for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 00:01:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.834
X-Spam-Level:
X-Spam-Status: No, score=-9.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 wBbn04r8joB6 for <6lowpan@core3.amsl.com>; Thu, 25 Jun 2009 00:01:28 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6735E3A6C7D for <6lowpan@ietf.org>; Thu, 25 Jun 2009 00:01:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,289,1243814400"; d="scan'208";a="43610919"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Jun 2009 06:44:25 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5P6iODf003834; Thu, 25 Jun 2009 08:44:24 +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.14.3) with ESMTP id n5P6iOLi029279; Thu, 25 Jun 2009 06:44:24 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); Thu, 25 Jun 2009 08:44:24 +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: Thu, 25 Jun 2009 08:44:20 +0200
Message-ID: <7892795E1A87F04CADFCCF41FADD00FC07ABAA60@xmb-ams-337.emea.cisco.com>
In-Reply-To: <87prctxu4g.fsf@kelsey-ws.hq.ember.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: piggybacked fragment ACKs
Thread-Index: Acn1CQYdep6gTqmJRvqSWkkKbYmDrQAVobNw
References: <87prctxu4g.fsf@kelsey-ws.hq.ember.com>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Richard Kelsey <richard.kelsey@ember.com>
X-OriginalArrivalTime: 25 Jun 2009 06:44:24.0836 (UTC) FILETIME=[60E9A440:01C9F560]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1439; t=1245912264; x=1246776264; c=relaxed/simple; s=amsdkim1002; 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=20piggybacked=20fragment=20ACKs |Sender:=20; bh=xVsxvMb4fEu3LbhCKH2BijOHSuR2ASnilNZMCpX9TsI=; b=Hjgh24Vz/k2M4ehzEkYV7I7o48VekaTkh5TyULa7zirHy4DTuNUx+yIcTd /7jbD5/ZXtXufN+i/Dg1y06YfD3V3ve+m4KCqT0QZ27k3QSlSGnMKeFOOMXN Te52FiR8M1;
Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] piggybacked fragment ACKs
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: Thu, 25 Jun 2009 07:01:29 -0000

Hi Richard:

I fully agree with Carsten; Also: 

FRACK might be used as a pacing mechanism, to limit the number of
outstanding fragments. When we get there, we might want to send a lot
more FRACKs than we do today, in which case piggybacking could be
useful, as long as there is reverse traffic that can be used for that
purpose.

An example of that is a slow firmware upgrade. Firmware chunks are
fragmented towards a device. The device piggy backs the FRACKs with the
sensor data. An outstanding window protects the network when many
devices are upgraded in parallel.

Note: I would not delay (too much?) the FRACK just to be able to piggy
back.

Pascal

>-----Original Message-----
>From: Richard Kelsey [mailto:richard.kelsey@ember.com]
>Sent: mercredi 24 juin 2009 22:19
>To: Pascal Thubert (pthubert)
>Cc: 6lowpan@ietf.org
>Subject: piggybacked fragment ACKs
>
>Pascal,
>
>In the past I have found it very useful to be able to
>piggyback ACKs on other traffic.  From reading RFC4944 and
>draft-thubert-6lowpan-simple-fragment-recovery-05 it looks
>like there should be no problem prepending an RFRAG-ACK
>header at the beginning of a LoWPAN datagram, as RFC4944
>does with various other headers.  On the other hand, I can't
>find anything that explictly allows this.  Do you see any
>difficulty with piggybacking RFRAG-ACKs on other packets?
>
>                               -Richard Kelsey

v2.23.0 | Report a Bug | By Email