Subject: Re: [Roll] Metrics ID, need for a new 'fill ratio' metric

From: Nicolas DEJEAN <[email-masked]>
Date: Thu, 1 Jul 2010 14:21:03 +0200

Phil,

2010/6/30 Philip Levis <[email-masked]>:
>
> On Jun 30, 2010, at 12:08 PM, Nicolas DEJEAN wrote:
>
> Recommendation
>
> -----------------
>
> We concluded that statements of MUST/SHOULD/MAY relating to the 'O' bit have
> to only related to *when* the bit is set, and can't relate to how a node
> *responds* to hearing the 'O' bit.
>
> For example, CTP started with saying that a node, upon hearing the 'O' bit
> set, MUST NOT route through a node until it hears the 'O' bit cleared. This
> was a disaster. The text now reads that a node MUST set the 'O' bit when it
> drops a packet due to a queue overflow. Of course, if you don't specify
> either when to set it or what to do when it is set, then the bit is
> meaningless.
>
> What I understand here is that the conclusion of your experiments is
> that the 'O' bit cannot be used as I described. Right?
>
> I wouldn't go that far. Instead, we tried for a good six months to make it
> work as described and concluded it probably wasn't the right approach.
>

Understood.

>
> So what do we have?
>
> About the 'O' bit, the metrics-07 is aligned with your recommandations.
> (My own interpretation was not and I thank you again for all the details.)
> Moreover, the meaning of this flag is clearly expressed as "may not be
> able to process traffic". Some text also describes how it could be
> used in a similar way than IS-IS.
> However, for the moment, how to set the bit and what to do when it is
> set is described as outside the scope.
> Does CTP propose a solution about what to do when hearing the 'O' bit?
>
> It does not propose a solution. We tried a few and none worked well. So we
> have left it as an open question.
>

OK metrics-07 also leave it as an open question.

> The 'fill ratio' metric I described has really a different meaning and
> should be managed in a separate metric as an implementation could use
> both mechanisms (but also for clarity and usage as a constraint).
>
> What do you think?
>
> I don't know. I tend to be pretty conservative in these things. Wireless
> protocol design is littered with so many ideas that looked good on paper but
> didn't work well in practice. So I generally shrug until I've seen
> supporting data from real-world networks. I don't see any reasons off the
> top of my head why the metric you proposed would be unlikely to work in
> practice, but there very well could be some that none of us know.

In fact, this 'metric' has not only studied on paper.
This is something we use in almost all our deployments (coupled with
other metrics for sure, like Hop Count and LQL) and that provided good
pro-active load balancing into our networks. Clearly, this is
something usable only when the traffic flow generated by the network
is known a priori. But this is not something new. An industrial usage
in the field has shown a real interest of such a method.

In these conditions, would be OK for including this new type of metric?

> Phil

Cheers,

Nicolas.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Jul 2010 14:31:19 +0200

[sorry for the previous wrong subject line]

Le 30/06/2010 19:23, Philip Levis a écrit :
>
> On Jun 30, 2010, at 8:54 AM, Alexandru Petrescu wrote:
>
>> Le 30/06/2010 17:03, Pascal Thubert (pthubert) a écrit :
>>> cribed.
>>>
>>> Anything else we need to add / update / delete ?
>>
>> Yes add IPsec AH I can write text if you need.
>
> Alex,
>
> Are you suggesting that AH should replace the current security
> mechanisms, or that it's an additional option?

Replace.

IPsec AH covers ICMP completely and potentially other headers proposed
for RPL in 6MAN - it would be worthless to have two signatures one IPsec
and one issued from Abit CCM*.

Proposal to write IPsec AH first, and make the current (A) bit and CCM*
optional enhancements.

Alex

> Phil

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Thu, 1 Jul 2010 05:40:06 -0700

> In these conditions, would be OK for including this new type of metric?

Seems like a good idea to me. Standardizing how RPL/LLN nodes exchange this kind of information is important. This leaves it open to future specifications to describe best practices for computing and using the information. It might be that current practices will work fine, or that there's something different enough about RPL that it requires some changes or modifications to current practice.

Phil

---

From: [email-masked]
Date: Thu, 1 Jul 2010 13:09:36 +0000

I am completely opposed to this proposal.  We should not add ipsec to the rpl draft.

Don
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Alexandru Petrescu <[email-masked]>
Sender: [email-masked]
Date: Thu, 01 Jul 2010 14:31:19 
To: Alexandru Petrescu<[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Roll] LC RPL-10

Replace.

Alex