Re: [6lo-fragmentation-dt] Performance report for fragment forwarding

Carsten Bormann <cabo@tzi.org> Wed, 19 September 2018 04:55 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6lo-fragmentation-dt@ietfa.amsl.com
Delivered-To: 6lo-fragmentation-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE58130F3F for <6lo-fragmentation-dt@ietfa.amsl.com>; Tue, 18 Sep 2018 21:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR8qZ--ldTrE for <6lo-fragmentation-dt@ietfa.amsl.com>; Tue, 18 Sep 2018 21:55:38 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305CD130DE0 for <6lo-fragmentation-dt@ietf.org>; Tue, 18 Sep 2018 21:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w8J4tT4Q026994; Wed, 19 Sep 2018 06:55:29 +0200 (CEST)
Received: from [192.168.2.102] (p54A6C3C7.dip0.t-ipconnect.de [84.166.195.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42FSGm6DWdzDXWd; Wed, 19 Sep 2018 06:55:28 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAO0Djp37FHUaoLPEhfLMX2dmEb+=DY0XdYLUDvq1AOuT9to8ZQ@mail.gmail.com>
Date: Wed, 19 Sep 2018 06:55:28 +0200
Cc: 6lo-fragmentation-dt@ietf.org, rabinarayans@huawei.com, yasuyuki.tanaka@inria.fr
X-Mao-Original-Outgoing-Id: 559025727.693072-bd18a2db3dc75170c73124108b8b0e1c
Content-Transfer-Encoding: quoted-printable
Message-Id: <6069A8FE-34B7-404D-9894-CD29B89FB36F@tzi.org>
References: <CAO0Djp2EKyiZK5-b+_R4c557mXSktPCEtYxOQjQb4vreTVOX9g@mail.gmail.com> <C3A37ED0-C93B-4D1B-9E6D-857B14253874@tzi.org> <CAO0Djp37FHUaoLPEhfLMX2dmEb+=DY0XdYLUDvq1AOuT9to8ZQ@mail.gmail.com>
To: Rahul Jadhav <rahul.ietf@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo-fragmentation-dt/UocGpj17JQoheZI2_vhFTmUOo8U>
Subject: Re: [6lo-fragmentation-dt] Performance report for fragment forwarding
X-BeenThere: 6lo-fragmentation-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 6lo Fragmentation Design Team <6lo-fragmentation-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo-fragmentation-dt>, <mailto:6lo-fragmentation-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo-fragmentation-dt/>
List-Post: <mailto:6lo-fragmentation-dt@ietf.org>
List-Help: <mailto:6lo-fragmentation-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo-fragmentation-dt>, <mailto:6lo-fragmentation-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2018 04:55:40 -0000

Hi Rahul,

> Carsten also mentioned a pacing mechanism .. while it might improve fwding efficiency it will add to buffer requirement. Also such a scheme might be non-trivial to be implemented.

Pacing is something the origin of the datagram does; I wasn’t suggesting the forwarders to add that (which indeed essentially puts the datagram into buffers there).
Clearly, pacing is counterproductive when forwarders do full reassembly, as it increases the time the partially assembled datagram is vulnerable to fragments of other datagrams hijacking the buffer — you want to capture the channel as much as possible then (to the level that you’d want to send following fragments with a higher MAC priority).  Of course, as the datagram travels through the network, it will become more and more smeared over time.

It would be interesting to see how your numbers change with some pacing at the origin; it should be easy to hack that in if you are not trying to do this in a general way.

> Regarding keeping higher mac-retry, ... We have chosen mac-retry of 3 after some experimentation (considering expected node densities and tx frequency). increasing mac-retry might not necessarily help, in fact it may backfire in terms of both PDR as well as mean latency. Would you still suggest to give it a try and what mac-retry do you think makes sense ?

Yeah, yet another tunable that in a robust protocol really should be self-tuning.
A MAC-layer retransmission is not useful if the layers above have already timed out.
So the latency introduced by the backoff mechanism is really the determining factor here.

Grüße, Carsten