Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

peter van der Stok <stokcons@xs4all.nl> Thu, 25 October 2012 11:28 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D1D21F89BE for <roll@ietfa.amsl.com>; Thu, 25 Oct 2012 04:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level:
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC-v1PmvM0sA for <roll@ietfa.amsl.com>; Thu, 25 Oct 2012 04:28:30 -0700 (PDT)
Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2F04D21F89B4 for <roll@ietf.org>; Thu, 25 Oct 2012 04:28:30 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id q9PBRuOU065407; Thu, 25 Oct 2012 13:27:57 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 25 Oct 2012 13:27:56 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Thu, 25 Oct 2012 13:27:56 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: roll@ietf.org, jonathan hui <jonhui@cisco.com>, richard kelsey <richard.kelsey@silabs.com>
Organization: vanderstok consultancy
Mail-Reply-To: <consultancy@vanderstok.org>
In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com>
References: <03B78081B371D44390ED6E7BADBB4A77220226E7@xmb-rcd-x02.cisco.com>
Message-ID: <17c4d278837c229b90fe6585a0f487fa@xs4all.nl>
X-Sender: stokcons@xs4all.nl (BAVYi/onJ4FZAJcKsyaHtK+DuG+8W+BW)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.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: Thu, 25 Oct 2012 11:28:32 -0000

Dear Richard and Jonathan,

We are quite happy with this new draft but I should like to comment on 
two aspects which need improvement according to me. (next to my earlier 
remark about implementation of MC domain)

Multicast message encapsulation:
For our applications it is important that the MC control message fits 
into one link-layer frame. Simulations show that with fragmented 6LoWPAN 
packets the MPL behavior becomes quite unpredictable unless specific 
measures are taken in all transmitting nodes. Knowing that the payload 
of a MPL packet is around 60 bytes, and may be further reduced by 
security overhead (see draft-keoh-tls-multicast-security-00), every byte 
of payload counts. Therefore I suggest that the original MC message can 
be distributed inside the LLN network without the encapsulation by the 
MPL message. I can very well imagine that encapsulation is needed to 
send the message to the seed (from inside the LLN network or from 
outside), but once it reaches the seed within the LLN, transmission of 
the original MC message inside the LLN is recommended without the 
encapsulation but including the MPL option in the header of the original 
MC packet. The MPL-2 draft suggests that when the MPL domain is composed 
of multiple MPL link-local scopes (even when contained within the LLN) 
each MPL forwarder encapsulates and decapsulates. I suggest that the 
wording is changed such that this is not necessary as long as the MC 
packet travels within the LLN.

Forwarder behavior:
The draft describes that sending of ICMP messages can be suppressed by 
setting REACTIVE_TIMER_EXPIRATIONS to zero. I like to suggest the same 
possibility for PROACTIVE_TIMER_EXPIRATIONS. The motivation is the 
following: In rather dense networks, it would be beneficial to reduce 
the number of forwarders. However, the non-forwarders may not receive 
some messages in spite of the density. By allowing these nodes to use 
the sending of ICMP messages, the forwarding nodes can be informed of 
the missing message to trigger a retransmission


Peter van der Stok


JP Vasseur (jvasseur) schreef op 2012-10-25 08:55:
> Dear all,
>
> draft-ietf-roll-trickle-mcast-02  has been discussed on the mailing
> list and during WG meeting a number of time; the document is stable
> and
> has been implemented. Thus this starts a 2-week WG Last call ending
> on Nov 9 at noon ET. Please send your comments to the authors
> and copy the mailing list and the co-chairs.
>
> Thanks.
>
> JP.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll