Re: [6lo] draft-gomez-6lo-optimized-fragmentation-header-00

"Carles Gomez Montenegro" <carlesgo@entel.upc.edu> Tue, 01 November 2016 20:47 UTC

Return-Path: <carlesgo@entel.upc.edu>
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 4A2E31299ED for <6lo@ietfa.amsl.com>; Tue, 1 Nov 2016 13:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 7jWCIqtmkx1f for <6lo@ietfa.amsl.com>; Tue, 1 Nov 2016 13:47:22 -0700 (PDT)
Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908F61294D8 for <6lo@ietf.org>; Tue, 1 Nov 2016 13:47:21 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id uA1Kl9Kj001298; Tue, 1 Nov 2016 21:47:09 +0100
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 2B6B01D53C1; Tue, 1 Nov 2016 21:47:08 +0100 (CET)
Received: from 79.156.3.232 by webmail.entel.upc.edu with HTTP; Tue, 1 Nov 2016 21:46:27 +0100
Message-ID: <bcbf93ef60cfa956406c26a81a39363d.squirrel@webmail.entel.upc.edu>
In-Reply-To: <87twc0nxoa.fsf@hobgoblin.ariadne.com>
References: <87twc0nxoa.fsf@hobgoblin.ariadne.com>
Date: Tue, 01 Nov 2016 21:46:27 +0100
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
To: "Dale R. Worley" <worley@ariadne.com>
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.98.7 at dash
X-Virus-Status: Clean
X-Greylist: Delayed for 00:55:55 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Tue, 01 Nov 2016 21:47:09 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/G6DpcapqyozyBg3pA4pZE4rtr9Q>
Cc: 6lo@ietf.org
Subject: Re: [6lo] draft-gomez-6lo-optimized-fragmentation-header-00
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 01 Nov 2016 20:47:23 -0000

Hi Dale,

Thanks for your e-mail, and sorry for the late response.

Well, Pascal already replied, so I'll just add some additional comment
(inline):

> "Carles Gomez Montenegro" <carlesgo@entel.upc.edu> writes:
>> This document proposes a more lightweight and compact 6LoWPAN
>> fragmentation header, compared with the one defined in RFC 4944.
>
> This seems like an improvement to me, though I'm new here.

Thanks!

> But this is a good time to ask my newbie question:  I see this
> definition of the "datagram size" field:
>
>    datagram_size: This 11-bit field encodes the size of the entire IP
>    packet before link-layer fragmentation (but after IP layer
>    fragmentation).  For IPv6, the datagram size SHALL be 40 octets (the
>    size of the uncompressed IPv6 header) more than the value of Payload
>    Length in the IPv6 header [RFC4944] of the packet.  Note that this
>    packet may already be fragmented by hosts involved in the
>    communication, i.e., this field needs to encode a maximum length of
>    1280 octets (the required by IPv6).
>
> Naively, it seems to me that link fragmentation is at a layer lower than
> link compression (e.g., LOWPAN_IPHC), so this datagram_size value is the
> length of the IPv6 packet (possibly an IPv6 fragment) as compressed by
> LOWPAN_IPHC.  If that is so, the above text isn't quite right, as
> e.g. the compressed packet might be shorter than the (reconstructed)
> Payload Length in the IPv6 header.

Well, the text is the same as in RFC 4944. I get your idea, but
datagram_size was actually defined as the size of the uncompressed IPv6
packet.

I understand that the advantage was that the receiver could determine
exactly how much buffer space was needed for the packet reassembly.

Cheers,

Carles

> Now maybe I'm wrong, and "datagram size" is the length of the
> uncompressed IPv6 packet, but then I don't see how the receiver is to
> know when all of the fragments have arrived.
>
> Dale
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>