Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments

Federico Consoli <admin@ipv6it.org> Sat, 05 May 2012 17:11 UTC

Return-Path: <admin@ipv6it.org>
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 BD78321F84E7 for <roll@ietfa.amsl.com>; Sat, 5 May 2012 10:11:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5yGwrOcj2eN for <roll@ietfa.amsl.com>; Sat, 5 May 2012 10:11:23 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA93321F84D9 for <Roll@ietf.org>; Sat, 5 May 2012 10:11:22 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so2581350wgb.13 for <Roll@ietf.org>; Sat, 05 May 2012 10:11:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ep2H8tOdSjlnjXwktbbzLQKrZqALYRyktyfuyZauT4M=; b=VpOLY8eXstaQrn79nAMVOSL/9L5dr5bKG4kcPQIMVxjFCQcN4/vsw+6zpAJoqf/XAg 0g2P4fUCNMJ1jRLB6xdIbA3tf2mH7j5fCLgBXzy59dIrUcOf32MDqT2FduGUI4ueRfTy We2m/s4To3T6KW2j6kBfq2FDPsII5GMHv1W2+Ysf13C+IpuCevuL9rcSETPvXFvxbyjF LFMj13nZEO8QaHnkMrGkkxpEjy4LKgOUL97hzIevZxXHSa5UsYL0YJB8XgAmF2hf1nzH ht4UtxEDFNm8xs/t15TytoU/qd1JGPKxgN737j0K6QS8F0MOee8k55TbjYPIeMxUZu5+ 2tIw==
Received: by 10.180.105.69 with SMTP id gk5mr25463408wib.3.1336237881816; Sat, 05 May 2012 10:11:21 -0700 (PDT)
Received: from [127.0.0.1] (host77-121-dynamic.8-87-r.retail.telecomitalia.it. [87.8.121.77]) by mx.google.com with ESMTPS id fn2sm11194314wib.0.2012.05.05.10.11.20 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 10:11:21 -0700 (PDT)
Message-ID: <4FA55F33.2030308@ipv6it.org>
Date: Sat, 05 May 2012 19:11:15 +0200
From: Federico Consoli <admin@ipv6it.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Roll@ietf.org
References: <387137981.280728.1336236660623.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <387137981.280728.1336236660623.JavaMail.root@mail17.pantherlink.uwm.edu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmlZSA8+oIDKQd9y2I42inaJ+14ukbgfZuwQmBNAewYVBz/iozQfV2XeFqa2IF8sxKUF0t4
Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Sat, 05 May 2012 17:11:23 -0000

Il 05/05/2012 18.51, Mukul Goyal ha scritto:
>> [Federico]
>>> The situation that I describedcan be seen from another point of view.
>> Suppose now that A and B got about 15-20 neighbor.
>> A got a rank of 500
>> B got a rank of 3000
>>
>> A suppresses DIOs for the reason described previously so node B will
>> continue to use a bad path for a very long time because it does "not
>> know" that node A "exists". I think that K should be at least =2 or more.
>>
>> [Mukul]
>> Continue using bad path? The route discovery is still going on! In the scenario you described, B probably will take a long time to be "discovered" or perhaps not be discovered at all within the specified DAG lifetime.
> [Federico2]
> Exactly, do not you think that the fact that node B take a long time to
> discover node Ais a problem?
>
> [Mukul2]
> No, it is not if B also has 15-20 neighbors like A. As long as the origin discovers a path to B that meets the specified constraints, there is no problem. It does not matter if the discovered path is through A or not.
>
> [Federico2]
>   Suppose that node B wants to communicate
> with a neighbor of node A, it could lead to sending many unnecessary DIOs.
>
> [Mukul2]
> You described two separate scenarios:
> 1) A has 15 neighbors, B has just A as the neighbor.
> 2) Both A and B have 15 neighbors including each other.
>
> In the second scenario, K=1 definitely makes sense because there are many candidate paths and one such path to B would probably be discovered even though many of B's neighbors would end up suppressing their DIOs. It is possible that the discovered route wont pass through A.
[Federico3]
I think this is the problem, the fact that the node B does not have full 
information about the status of his neighborhood. In the second scenario 
node B will use a path almost certainly worse to reach a neighbor of the 
node A.
> In the first scenario, discovery of a route to B depends on A making a DIO transmission and B receiving it. This would be delayed if A ends up suppressing its DIO again and again. The route discovery would fail if DAG lifetime is over before B could receive the A's DIO. If that is very likely to happen in a particular deployment, K should not be 1. No doubt about it. But, we cannot set the K value in default configuration option to account for this case, which is certainly not the common case.
>
> Thanks
> Mukul
>
>
>>> On the other hand, if Imin/K are set less conservatively, you might see too many DIOs generated. There is no silver bullet. No single setting would work well in all situations. We do provide some guidance on how to set trickle timer in Section 9.2 of the draft. The trickle parameter values in default configuration option are a conservative estimate based on the desire to avoid too many DIOs. If these settings are not OK for a particular deployment, well then the default configuration option should not be used. The connectivity variance you described is indeed a tricky situation and would require a tradeoff with the need to avoid generating too many DIOs. I imagine one possible solution could be to allow a node to set its k based on its position (rank) in the DAG (k increases as you move closer to the edge). But, again there might be cases where this (or any other fix) wont work.
>>>
>>> Thanks
>>> Mukul
>>>
>>> ----- Original Message -----
>>> From: "Federico Consoli"<admin@ipv6it.org>
>>> To: roll@ietf.org
>>> Sent: Saturday, May 5, 2012 4:04:09 AM
>>> Subject: [Roll]  I-D Action: draft-ietf-roll-p2p-rpl-10 comments
>>>
>>> Hi,
>>> I disagree with the default value of trickle timer, especially for
>>> Imin=6 and K=1.
>>> If you got a dense network it could lead to a very long time to build DAG.
>>>
>>> Eg. Suppose you got 2 node A, B.
>>> Node A got about 15-20 neighbor
>>> Node B got only A as a neighbor.
>>>
>>> When node A receive its first DIO it resets trickle to Imin and it
>>> starts trickle timer. Since A got a lot of neighbor its probably receive
>>> another consistent DIO so it will suppress the DIO message and it will
>>> increase its Imin to 7. So if node A suppress 6-8 times its DIO node B
>>> will receive it after a long time. Finally if the link A-B got an ETX of
>>> 2 or 3 (or more) this time doubles.
>>>
>>> These situations are not uncommon, especially in the routers at the edge
>>> of dense networks.
>>>
>


-- 
Regards
Consoli Federico