IETF Logo Mail Archive

Re: [6lo] [6tisch] Thomas' review of draft-thubert-6lo-forwarding-fragments-04

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 06 April 2017 17:17 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC8F129488; Thu, 6 Apr 2017 10:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 hoQX5sR_MkDw; Thu, 6 Apr 2017 10:17:37 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3752F1294A0; Thu, 6 Apr 2017 10:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13338; q=dns/txt; s=iport; t=1491499057; x=1492708657; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iPPhh8gvHtPI11ZojByF2+h8EbpAI6OLecO640N1xgQ=; b=X9olmBM3NFTzVSx0/c9S1ZLfAAGKm8TVz0VZQWF5MGpjWA8AXz++riIg t5sPex7TnxjdBcpsfOJiKP7AjVHj05005imo8L0MAp4WiZMp21hBRK8QQ EqPzomSr37Rl5oUnUdmp6bEcI78FfVTZcHFQ5ViudQZca6GqxFLOl/Fjw g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ATAgB8d+ZY/5tdJa1cGQEBAQEBAQEBAQEBBwEBAQEBgm5mYYELB4NcihKRPYgaiAeFNIIPhiICGoMsPxgBAgEBAQEBAQFrKIUVAQEBAQMjCkwQAgEGAhEEAQEBJwMCAgIfERQJCAIEAQ0FCIluAxWMbJ1dgiaHLA2DLgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToRwglGCO4JQgl8Flh2GGzsBjhmEMIIHhS6KEYp7iHwBHziBBVsVhxx1iFKBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.37,160,1488844800"; d="scan'208,217";a="227580666"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 17:17:36 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v36HHaWW026234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Apr 2017 17:17:36 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Apr 2017 12:17:34 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Thu, 6 Apr 2017 12:17:35 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Rahul Jadhav <rahul.ietf@gmail.com>, Thomas Watteyne <thomas.watteyne@inria.fr>
CC: "6tisch@ietf.org" <6tisch@ietf.org>, lo <6lo@ietf.org>
Thread-Topic: [6tisch] [6lo] Thomas' review of draft-thubert-6lo-forwarding-fragments-04
Thread-Index: AQHSpz1gbZRIvsYUX0eo4E0mrs/jUKG1SrIQgAMdW/yAADvWYA==
Date: Thu, 06 Apr 2017 17:17:17 +0000
Deferred-Delivery: Thu, 6 Apr 2017 17:17:09 +0000
Message-ID: <71941304d1c741bb966a7bce533bf9b9@XCH-RCD-001.cisco.com>
References: <CADJ9OA9AX6N+-pciaCxyO-oWNft2fwKf8OXSn71VDi+tdXHoKw@mail.gmail.com> <23d281df0e12472b91791f6173485f75@XCH-RCD-001.cisco.com> <CAO0Djp11QNhV1MUtHXbw-ZLXT3mkxLOKUasATvNfmWxAvPhoPg@mail.gmail.com> <9C5FC3F7-D2D8-4B0A-B642-9E92861C9E12@tzi.org> <CAO0Djp35HfbyxAaCuUtd5Snkad7foYNLDW3ew_XkE7DORtQ5AA@mail.gmail.com>
In-Reply-To: <CAO0Djp35HfbyxAaCuUtd5Snkad7foYNLDW3ew_XkE7DORtQ5AA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.4]
Content-Type: multipart/alternative; boundary="_000_71941304d1c741bb966a7bce533bf9b9XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/ol-QqCVPD-9NxY5zeyZcd2zXNi8>
Subject: Re: [6lo] [6tisch] Thomas' review of draft-thubert-6lo-forwarding-fragments-04
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Apr 2017 17:17:39 -0000

That ultra cool Rahul.

I published 05 that addresses Thomas’ comments ☺

And yes, there’s a lot more than forwarding fragments blindly.

Take care,

Pascal



From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Rahul Jadhav
Sent: jeudi 6 avril 2017 15:40
To: Carsten Bormann <cabo@tzi.org>
Cc: 6tisch@ietf.org; lo <6lo@ietf.org>
Subject: Re: [6tisch] [6lo] Thomas' review of draft-thubert-6lo-forwarding-fragments-04

Hi Carsten,

Currently I m reassembling hop by hop.

Problem begins with initial auth session itself!! I use PANA for network access in single channel (with no RDC) mesh and the payload in most PANA messages crosses 127B (especially considering the relay header overhead),,, its all unicast with MAC layer ACK. None of my mcast packets cross MTU boundary. Also an imp point is that the buffer space is only for one IPv6 datagram (i.e. 1280B).
Some of the problems highlighted by Pascal such as, fragments getting discarded prematurely for e.g. because of high node density causing reception from different peers is hurting the end to end msg transmission badly. The failure rate and thus the retransmission rate at app is very high,, so much that we had to adopt a proprietary compressed PANA signalling mechanism  to improve convergence time.

Regards,
Rahul

On 6 April 2017 at 18:24, Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:
On Apr 6, 2017, at 10:57, Rahul Jadhav <rahul.ietf@gmail.com<mailto:rahul.ietf@gmail.com>> wrote:
>
> Fragmentation at 6lo layer as it is today is almost unusable for a moderately sized network with lower MTUs such as 127B.

Hi Rahul,

please explain some more.

What kind of problem do you experience?

Is the load on your network predominantly composed of packets > 127 B?

Are you using MAC-layer ACK?

Do the problems you are seeing occur with Unicast or with Multicast?

Are you already using fragment forwarding or are you reassembling hop by hop?

Grüße, Carsten

v2.23.0 | Report a Bug | By Email