Re: [Lwip] [6lo] [E] fragment forwarding implementation and performance report

"Chakrabarti, Samita" <> Tue, 09 October 2018 15:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5241013133B for <>; Tue, 9 Oct 2018 08:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=GhjJWlMc; dkim=pass (2048-bit key) header.b=XALih5sU
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EagSXpnAnoiJ for <>; Tue, 9 Oct 2018 08:04:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FAAE131338 for <>; Tue, 9 Oct 2018 08:04:46 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w99F4e6v134833 for <>; Tue, 9 Oct 2018 11:04:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp; bh=H2ly3GbT876nIfuwkyhbb5Szl3ZYRLEvfxzNBmhJ6+o=; b=GhjJWlMci5XXQajzFN/o0Meek8xe4S23mHsfPcODEnoAJIPARLTLRo/zc0SGa2hfcaGQ 6UUcYXvVxvGI/8Rju3oILMB+3p12oqSoacgvy7frfc4ied+mgpDd2cDD6edssoUg86ed BvBRfb3egSzcXFEr5OxKYyuL1h3N6ZILdz8=
Received: from ( []) by with ESMTP id 2n0x278je8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <>; Tue, 09 Oct 2018 11:04:41 -0400
Received: by with SMTP id j47so1252936ota.16 for <>; Tue, 09 Oct 2018 08:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H2ly3GbT876nIfuwkyhbb5Szl3ZYRLEvfxzNBmhJ6+o=; b=XALih5sUM6IIEmI2bPI4YSuP1RSQgvMjBUQbheCgrdpr49C2cyfDfFtW+fhlOxXYAV CMY1Dk9QBA0+w7OgALpUVjZYPsUSZK/OwokWqGji05+6M01ktDDnnhTOtIwkvNXL2D3s kvBS75OuF1SXuBHfMkBsl6rPcU6qdfeUVa4ByEAux09pZQobzTubE/EjW/ykl3Q1HGia rdE3DJzPuFeqDaweQUfCzP7JWLLMenFzJ9apLShbcy/ke6bVB+3PviqmV1kIaewvxRxd 23+gsT6txot+vlPUcuRaSM/KTCtwd3IKvnqu/ijv7EllPjfdsMuhS6FzepXVnHC3o5ZC Cr4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H2ly3GbT876nIfuwkyhbb5Szl3ZYRLEvfxzNBmhJ6+o=; b=lp34KhpDVMA2QstySHyzVcPCz3OJOXqZiTWgwbXpNUzb0exe4ODaYyZ6QrnE1NNXvX kzQ0RXQqzTAYvbucYG0qLUGObmyWi37g8boVvCbOJTF7c2Xq+MqSR0SYPEI1XtXSiQJa 06U9W2IHQRVNSspB08qYbvMRmIPB8UNJtveDL0yWJ8jKj+KMk17FUSU6NDleo1bXsaO3 /LKhoZxbmSKIKn/DsGoem/u0A815t53rTXIJSniCDimqB3vIKNDTrvJIDXrVeQ7z7ear B4wpPy4twde+iG33n1OhcT/JsTNRZc+B1j1/tG2TXfZ9dtzvSlsJu5FBVb9G4OugNHv7 W73Q==
X-Gm-Message-State: ABuFfoihq3V7brTvKL6fryJkwd+8+acLHsSp/9Iai2bRggiGGaCOWBS5 8ID6kfmi5MSkf4eiTsxsxTCG0WkA91YuLOI0Rprm+L18NTla+V3lVIJSb0sBpk3zDX6LK0CNY7D 5J1UuY9fpiQZW+DqYeISX
X-Received: by 2002:a9d:d61:: with SMTP id 88mr13141402oti.245.1539097457249; Tue, 09 Oct 2018 08:04:17 -0700 (PDT)
X-Google-Smtp-Source: ACcGV61fd/snF4u/sPGHvZ0Kue1raiMtrJotsEQLmS8TysErVZOM/vFHPJbMu8mxTBO0LwlXS1wcNoRTC1TgjOsnrfQ=
X-Received: by 2002:a9d:d61:: with SMTP id 88mr13141375oti.245.1539097456895; Tue, 09 Oct 2018 08:04:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: "Chakrabarti, Samita" <>
Date: Tue, 09 Oct 2018 11:04:05 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000317c240577cd0d21"
X-mailroute: internal
X-Proofpoint-Spam-Details: rule=out_spam_notspam policy=out_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=943 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810090147
Archived-At: <>
Subject: Re: [Lwip] [6lo] [E] fragment forwarding implementation and performance report
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Oct 2018 15:04:49 -0000

Hi Pascal,Thanks for the explanation on the following points.

On Tue, Oct 9, 2018 at 7:48 AM Pascal Thubert (pthubert) <>

> Hello Rahul and Samita :
> I thought, the performance would improve with higher X value,  but that is
> not true - perhaps due to increased payload size.
> Yes, the increased payload size causes higher number of fragments per
> payload which increases payload loss probability since a single fragment
> loss will cause complete payload failure.
> *[PT>] Yep: this shows the chances of not only losing the packet but
> buffer bloat on the receiver, which entails not having memory left for
> receiving normal packets. IOW this justifies doing recoverable fragments.*

It would be great to try out the intelligent fragment-forwarding draft
(Pascal's draft) on the same setup and show the difference in efficiency.

Just curious, in your estimate, does the forwarding issue show up more on
6tisch network compared to other technologies that don't have such reliable
This is something to think about for implementation recommendations-- for
example, intelligent fragment forwarding will be needed for efficient use
6tish network with payload range X and Y.
Similarly, if other technologies mostly use small payloads and can
reasonably work well with implementing minimal fragment forwarding, then
documenting that information will be very useful for deployment.


> Also, it shows that by controlling the pacing of forwarding the fragments
> the performance can be improved to a great degree in a medium to small size
> mesh. ( in this example, 50 nodes).
> What happens when you increase the mesh size ( aka number of nodes)?
> Yes we can increase the mesh size but then I do not think it will change
> the inferences much. We also wanted to try different (higher) node
> densities which I feel might further cause problems for fragment
> forwarding. Among other things we also want to experiment with fragment
> acknowledgement mechanism. But we haven’t really validated all these points.
> *[PT>] In a real network we can expect more than one flow. Here the one
> packet appears smooth but that’s because there is nothing to interfere
> with. What if you kept on sending packets continuously, and over multiple
> crossing paths?*
> *There are really 2 effects that justify pacing the fragments. With a
> channel hopping technology like TSCH, it is just to left the next hop
> forward the fragment, so the wait can be short. When using a single
> frequency, there is also avoidance of hidden terminal between consecutive
> fragments, which means that we have to wait for the fragments to relay over
> multiple hops.*
> *This tells us that the fragment forwarding technique is a lot more
> efficient when coupled with 6TiSCH. None of this is a surprised, all was
> described to the group when we started (see my slides from a few IETFS ago,
> see slide 32 of
> <>
> ).*
> *I hope others continue the great work that Rahul has started, in
> particular with TSCH and multiple flows.*
> *Take care,*
> *Pascal*