Subject: [Roll] Rank in HbH / FL

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Aug 2010 13:54:48 +0200

Hi Phil:

The use of the Rank in forwarding path is to differentiate up from down.
Only the floor(Rank) is needed, and that floor() can be made one octet
or less even for metrics that we rank in 2 octets.
The proposal is not to compress but simply to pass the useful
information as opposed to the waste we are currently observing in all
packets.
Note: Same floor means siblings, which the group selected not to use,
upon your suggestion.

Pascal

> -----Original Message-----
> From: Philip Levis [mailto:[email-masked]]
> Sent: Monday, August 09, 2010 5:59 PM
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; [email-masked]; Carsten Bormann; [email-masked]
> Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
> 
> 
> On Aug 9, 2010, at 3:17 AM, Pascal Thubert (pthubert) wrote:
> 
> > Hi Michael:
> >
> > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I
> > tried to stay within the lines of RFC 3697 as you also defend in
your
> > mail.
> >
> > I think the question we have now is not whether that proposal is
lawful
> > but whether the new law being defined at 6MAN would prevent it in
the
> > future.
> > If the updated rules allow, then I'll be glad to work on an FL-based
> > alternate to the IPinIP/HbH.
> >
> > It appeared at the 6MAN WG meeting that 12 bits mutable was exactly
what
> > the core network was asking for to do its load balancing.
> > A first question to the group could be whether 12 mutable bits are
> > enough for the sensible usages envisioned so far?
> 
> My 2c:
> 
> In the case of the hop-by-hop header, 12 bits is clearly enough for an
8-bit
> RPLInstanceId, but clearly not enough for a 16-bit Rank. I think that
trying to
> compress them (especially Rank) would be a mistake, whose complexity
would
> far outweigh the benefits.
> 
> Phil

---

From: Philip Levis <[email-masked]>
Date: Tue, 10 Aug 2010 09:54:39 -0700

> Note: Same floor means siblings, which the group selected not to use,

Pascal,

I understand what the goal is; I'm questioning whether it's technically feasible.

This works in some cases, but not all. E.g. if you use the entire 12 bits to represent Rank but MinHopRankIncrease is < 16 (0x10), then you cannot compress Rank properly. If you want to use fewer than 12 bits, then the constraint becomes tighter.

For some metric->Rank conversions, where the dynamic range is relatively small, such as ETX, then this constraint might be possible to satisfy. But there are some metric->Rank conversions, such as latency, where the dynamic range can be very high.

Yes, floor() *can* be made one octet in some cases. That does not mean it can be done so in all cases. Otherwise we have specified that MinHopRankIncrease is always >= 256. 

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Aug 2010 13:24:53 +0200

Hi Phil:

I would not mind specifying that min hop increase is >= 256. Also, the
FL approach is an alternate to the mainstream HbH.
At moment, only HbH Is available and we'll see where 6MAN goes. If
there's a way to use the flow label, then we'll document it. 

Best,

Pascal

> Sent: Tuesday, August 10, 2010 6:55 PM
> Cc: Michael Richardson; [email-masked]
> Subject: Re: Rank in HbH / FL
> 
> This works in some cases, but not all. E.g. if you use the entire 12
bits to
> represent Rank but MinHopRankIncrease is < 16 (0x10), then you cannot
> compress Rank properly. If you want to use fewer than 12 bits, then
the
> constraint becomes tighter.
> 
> For some metric->Rank conversions, where the dynamic range is
relatively
> small, such as ETX, then this constraint might be possible to satisfy.
But there
> are some metric->Rank conversions, such as latency, where the dynamic
range
> can be very high.
> 
> Yes, floor() *can* be made one octet in some cases. That does not mean
it can
> be done so in all cases. Otherwise we have specified that
MinHopRankIncrease
> is always >= 256.