Re: [Roll] [6tisch] call for consensus for the RPL RPI / RH3 compression

Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> Fri, 19 December 2014 17:32 UTC

Return-Path: <xvilajosana@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E4A1A9048; Fri, 19 Dec 2014 09:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 I4uzJ8RQfZct; Fri, 19 Dec 2014 09:32:42 -0800 (PST)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6321A9076; Fri, 19 Dec 2014 09:32:09 -0800 (PST)
Received: by mail-wg0-f53.google.com with SMTP id l18so1931802wgh.12; Fri, 19 Dec 2014 09:32:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uTgYA2c9GzNmQS1fbFEKXAz6SgAvGjDh1/eHXYYz+CU=; b=Z7qry5veDE25gtAb6NCWV2PnHLoBlyQ7SE5XPipHsveBHgKxwqIKM1msnRv4JydIdK HY0fJrWtHvOkroKM2KqY9yZAh1wvpHEnaJ1QX+gTYLlAts9QfPByfzedrpg50SxK3FvC yR0Dq0mNZs0Ub+ev0fauwUvgRydVd/4z6j6605mWtEQ65/nkDI3f86CQO9yV1RSDFdq9 zOJHA4NEnT/5d0VFgoK2BCda6khzR7bdlzCZiBr8+1ennSULvnzIRoCmAslenFqGBh/B Y7awBaEfZREjbgTnStmQqkJnGx/DKLdRmU9rDWwkQnyH6y+xXjFCqQmo3W94ZyQMv4OV qh1g==
MIME-Version: 1.0
X-Received: by 10.180.78.202 with SMTP id d10mr7979030wix.82.1419010327757; Fri, 19 Dec 2014 09:32:07 -0800 (PST)
Sender: xvilajosana@gmail.com
Received: by 10.27.210.201 with HTTP; Fri, 19 Dec 2014 09:32:07 -0800 (PST)
In-Reply-To: <54944A36.4000101@gridmerge.com>
References: <E045AECD98228444A58C61C200AE1BD848AC2314@xmb-rcd-x01.cisco.com> <184B78CA-953E-45AB-B00C-B3A12CFE4605@tzi.org> <E045AECD98228444A58C61C200AE1BD848AC7D04@xmb-rcd-x01.cisco.com> <54942758.6090705@innovationslab.net> <E045AECD98228444A58C61C200AE1BD848AC86C5@xmb-rcd-x01.cisco.com> <549440F0.8040407@innovationslab.net> <54944A36.4000101@gridmerge.com>
Date: Fri, 19 Dec 2014 18:32:07 +0100
X-Google-Sender-Auth: E1y8w485Br61uCXspVBKKPLQAWI
Message-ID: <CAMsDxWS3oyappFCYNFVe1pRTxhnse1PLA-wx4O7Y=+GOCHQm5g@mail.gmail.com>
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
To: robert.cragie@gridmerge.com
Content-Type: multipart/alternative; boundary=f46d043c084884c83c050a9516f1
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/NI7iLLlFXoNGzwo2hmFWg4IY6_8
Cc: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "6lo-chairs@tools.ietf.org" <6lo-chairs@tools.ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "int-ads@tools.ietf.org" <int-ads@tools.ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [Roll] [6tisch] call for consensus for the RPL RPI / RH3 compression
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Dec 2014 17:32:46 -0000

Hi,

I do not think this is an implementation problem. It seems to me an
architectural problem. If we want to compress the HbH routing header we
have to decide for the best approach and do it once. Flow label is an
option that we tested but it is not aligned to the way IPHC headers are
compressed and we discussed this for weeks at 6tisch. We already know most
of the PROS and CONS of the approaches being discussed but the problem I
guess it is not performance or number of bytes saved but the coherence of
the procedure of compressing the header with respect to the IPHC approach.

If going for a NHC or RH3 may take years at 6lo we have the option to stay
with current HbH header approach or push for flow label knowing that due
time constraints we cannot do it better but I do not thing that testing
would solve this coherence problem.

regards,
Xavi



2014-12-19 16:54 GMT+01:00 Robert Cragie <robert.cragie@gridmerge.com>om>:
>
>  +1.
>
> It sounds like an interop would be the ideal place to test out the various
> hypotheses on the respective proposals.
>
> Robert
>
>
> On 19/12/2014 15:14, Brian Haberman wrote:
>
> On 12/19/14 10:01 AM, Pascal Thubert (pthubert) wrote:
>
>  That's interesting, Brian.
>
> We decided that for completeness of its expression of the RPL
> operation, the draft should provide a pointer on the way the RPL info
> is carried. We need a minimum set of common stuff to interop and the
> way to express the RPL information is one. We can live with any
> default as long as everyone implements it. Now if optionally people
> support additional ways to make comparisons with that reference, that
> would certainly be good, if the question is still open at that time.
> All in all, if you agree, we can progress the draft in IESG review
> leaving that particular reference open to be changed till later in
> the process?
>
>  Why would you expect that to be acceptable?  If a piece of the spec is
> needed for interoperability, it needs to be there during the review.
> Why send it to the IESG if there are still questions on how that piece
> will be done?  If it is left out, how will anyone know if there is
> consensus on the spec as a whole?
>
> It seems to me that:
>
> 1. There have been several proposals put forth
>
> 2. Issues have been raised on each one
>
> So, it seems prudent (to me) to look at each of the alternatives and
> determine which warts everyone concerned is willing to live with.
> Running code is a good way to do that.
>
> Making that determination needs to be done before the spec is sent to
> the IESG.
>
> Regards,
> Brian
>
>
>  Pascal
>
>
>
>  -----Original Message----- From: Brian Haberman
> [mailto:brian@innovationslab.net <brian@innovationslab.net>] Sent: vendredi 19 décembre 2014
> 14:26 To: Pascal Thubert (pthubert); Routing Over Low power and
> Lossy networks Cc: 6man-chairs@tools.ietf.org;int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo- chairs@tools.ietf.org Subject: Re: [Roll] call for consensus for
> the RPL RPI / RH3 compression
>
> Pascal,
>
> On 12/19/14 6:59 AM, Pascal Thubert (pthubert) wrote:
>
>  The rush Carsten,
>
> is that the document that will be the base for the 6TiSCH interop
> test in Prague is now in last call, and that document refers to
> the NHC draft. The question is what should it refer to, and
> whatever it refers to should be stable and implementable by now.
>
>  So, do you view the code for the interop being "set in stone"?  As
> Adrian pointed out, the interop could be a way to work out the
> tradeoffs of these multiple approaches.  That is, running code
> leads to an IETF specification rather than the other way around.
>
> Regards, Brian
>
>
>  Just the first (per your words) is just fine with me.
>
> Cheers,
>
> Pascal
>
>
>  -----Original Message----- From: Roll
> [mailto:roll-bounces@ietf.org <roll-bounces@ietf.org>] On Behalf Of Carsten Bormann
> Sent: vendredi 19 décembre 2014 09:17 To: Routing Over Low
> power and Lossy networks Cc: 6man-chairs@tools.ietf.org;int-ads@tools.ietf.org; 6tisch@ietf.org; 6lo-chairs@tools.ietf.org Subject: Re: [Roll] call for consensus
> for the RPL RPI / RH3 compression
>
> On 17 Dec 2014, at 09:29, Pascal Thubert (pthubert) <pthubert@cisco.com> <pthubert@cisco.com> wrote:
>
>  Decision in Hawaii was that the NHC draft could not be
> accepted as is, since we should compress also the RH3, and
> without a clear view of how that would happen, the details of
> the NHC compression could not be determined. So the NHC
> approach was abandoned
>
>  That is not at all what I recollect from Hawaii.
>
> The current smorgasbord is:
>
> — various ways to hijack the flow label (dead) — the 6553-NHC
> proposal — ideas for a new mesh header
>
> I’m not going to beat the dead horse of the flow label hijack.
>
> The 6553-NHC proposal mainly needs a decision between the
> three variants (flip a coin, if need be). If time is of the
> essence, 6553-NHC is the natural thing to do. We can always do
> an RFC 6554 NHC compression separately.
>
> The MH proposal is forward-looking and probably the right thing
> for the evolution of 6lo, but probably also not compatible with
> a tight time schedule.
>
> Now, what is the rush? RFC 6553/6554 do exist.
>
> So we get to choose between rushing 6553-NHC to completion or
> using 6553/6554 for now and doing the MH work right (or. more
> likely than just the first, both). I don’t have an opinion on
> wether we need to rush 6553-NHC, but if we need to rush
> anything, this one it is.
>
> Grüße, Carsten
>
> _______________________________________________ Roll mailing
> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing listRoll@ietf.orghttps://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>