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

worley@ariadne.com (Dale R. Worley) Wed, 26 October 2016 15:36 UTC

Return-Path: <worley@alum.mit.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 9C12912964F for <6lo@ietfa.amsl.com>; Wed, 26 Oct 2016 08:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 7Hl0_4RzWKxu for <6lo@ietfa.amsl.com>; Wed, 26 Oct 2016 08:36:01 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 D91701294C7 for <6lo@ietf.org>; Wed, 26 Oct 2016 08:36:00 -0700 (PDT)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-10v.sys.comcast.net with SMTP id zQCcbNCWlRingzQFEbFhfv; Wed, 26 Oct 2016 15:36:00 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4601:6182:222:fbff:fe91:d396]) by resomta-ch2-15v.sys.comcast.net with SMTP id zQFAb7zKfoJWizQFBb1HST; Wed, 26 Oct 2016 15:35:59 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u9QFZuAu023917; Wed, 26 Oct 2016 11:35:56 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u9QFZsOX023910; Wed, 26 Oct 2016 11:35:54 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
In-Reply-To: <c38b451dc407418491514cf303964562@XCH-RCD-001.cisco.com> (pthubert@cisco.com)
Sender: worley@ariadne.com
Date: Wed, 26 Oct 2016 11:35:54 -0400
Message-ID: <87eg33nmw5.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfGmfAPYqPZwr1vI/1I5R++pvyFN3Un4UaJhxVTmRzub7waBSO+qrtZu4IwF5JWwdxmP3oKSoYJrAR8ELdQCRuGuWfhKIPfSz4i8dfj23qh0q8NMhftej 1vYWkQMOU91u3amFpjIGsdOKWudkHOu+0B9CA6L82Jl6YT7CeB8xFkt4wwAKk3anWPvwnHGaushMP7m100MSuXcTJamyue/J5v4AMo+4C2uNp5P1+YaeSu2x 0SyTOl3DJ66Rpdb39w+qgw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/zBmXhiiSlrW-vXbp8iJFQZyAROU>
Cc: carlesgo@entel.upc.edu, thomas.watteyne@inria.fr, 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: Wed, 26 Oct 2016 15:36:02 -0000

"Pascal Thubert (pthubert)" <pthubert@cisco.com> writes:
> I agree... I think that the idea was to make sure that the buffer you
> prepare is big enough for the uncompressed form.

That is a useful property.

> When Jonathan and I wrote a proposed rework we changed that as you suggest:
> https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-02 
[...]
> The rework addressed the problems discussed in the attached slides,
> and which are still fully present today.
> The work needs support to move on. Last I checked interest was really limited.

As a general rule, people will show interest if they're being bitten by
the problem in practice.  If there isn't much interest, that would mean
that people aren't running into these problems in practice.  It's not
clear to me why that would be.

> Note also this text in RFC 6282: [...]

OK, I can see how that makes the packet reconstructable, as complicated
as that system is.  I do wonder why it was chosen, though, as it seems
both more complicated and less natural than separating compression and
fragmentation into two layers.

Dale