Subject: [Roll] higher priorities to RPL messages

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 5 Aug 2010 07:18:40 +0300

Hi,

Question to the group:

Does the group think a mechanism by which RPL messages will have higher
priority over data packets would be useful?

Without routing, data cannot go through.

If there’s a high congestion of data traffic in the network, it could slow
down or in some cases of link layers even completely disable the RPL
messages from being transmitted altogether.

Thoughts would be very much appreciated.

Thanks,

Yoav

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2010 11:12:48 +0200

Le 05/08/2010 06:18, Yoav Ben-Yehezkel a écrit :
> Hi,
>
> Question to the group:
>
> Does the group think a mechanism by which RPL messages will have
> higher priority over data packets would be useful?
>

That is right, if the routing tables are not set properly (with fields
from DIO messages) then data won't get through, despite the potential
presence of HbH or RH headers.

Makes some sense to attach higher priority to control messages, but how
would one do it?

> If there’s a high congestion of data traffic in the network, it could
>  slow down or in some cases of link layers even completely disable
> the RPL messages from being transmitted altogether.
>

ICMP has this kind of characteristic - it is control.  RPL messages are
of an ICMP Type.

How would one do it?  Traffic Class of RFC2460 mentions priority:
> The 8-bit Traffic Class field in the IPv6 header is available for
> use by originating nodes and/or forwarding routers to identify and
> distinguish between different classes or priorities of IPv6 packets.

How would this priority be implemented?

Are we looking at designing such a Class (reserve bits here and there)
and leave implementation behaviour to specify later?

Are we looking at diffserv/intserv things like rfc5455?

Are we looking at extending MPLS?

Are we looking at new fields to add to DIO/DAO to express this priority?

All these?

These are my comments,

Alex

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

---

From: Philip Levis <[email-masked]>
Date: Thu, 5 Aug 2010 10:27:26 -0700

On Aug 4, 2010, at 9:18 PM, Yoav Ben-Yehezkel wrote:

> Hi,
>  
> Question to the group:
> Does the group think a mechanism by which RPL messages will have higher priority over data packets would be useful?
> If there’s a high congestion of data traffic in the network, it could slow down or in some cases of link layers even completely disable the RPL messages from being transmitted altogether.
>  

My 2 cents:

This seems out of scope. It's an implementation decision, as it has implications based on what the underlying OS scheduling algorithm is. In the context of LLNs, at least, high congestion is not very common. We should assume that the OS or implementation does something intelligent, rather than enforce external policies. E.g., we expect OS kernels to schedule packets to different open TCP streams intelligently, rather than enforce some kind of scheduling policy.

I'll try to ground this in my experiences with the TinyOS implementation of CTP. TinyOS uses a round-robin packet scheduler at the link layer. Each packet send client (the best analogy to traditional OSes would be file descriptor) has one reserved slot in a queue, and the link layer scans this queue for packets to send[1]. If a packet source, such as a routing protocol, wants to support having more than a single pending transmission, it layers its own transmission queue on top of this link layer queue.

CTP has two packet send clients: one for data packets, one for control packets. This means that, even in the presence of high data traffic, a pending control packet has to wait at most one data packet before being transmitted, and in the worst case control packets receive 50% of the link throughput given to the routing protocol. The CTP implementation handles the starvation problem with an intelligent use of the underlying OS abstractions.

Phil

[1] tinyos-2.x/tos/system/AMQueueImplP.nc:nextPacket()

---

From: Richard Kelsey <[email-masked]>
Date: Thu, 05 Aug 2010 16:24:45 -0400

> From: Philip Levis <[email-masked]>
> Date: Thu, 5 Aug 2010 10:27:26 -0700

> > Does the group think a mechanism by which RPL messages
> > will have higher priority over data packets would be
> > useful?  Without routing, data cannot go through.  If
> > there’s a high congestion of data traffic in the
> > network, it could slow down or in some cases of link
> > layers even completely disable the RPL messages from
> > being transmitted altogether.
> 
> This seems out of scope. It's an implementation decision, as it has
> implications based on what the underlying OS scheduling algorithm
> is. In the context of LLNs, at least, high congestion is not very
> common.

For battery-operated LLNs, perhaps.  For ZigBee-style
line-powered LLNs, occasional congestion is not uncommon.

I do agree with Phil that dealing with congestion is out of
scope for RPL.
                                 -Richard Kelsey

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Sun, 8 Aug 2010 10:13:21 +0300

Thanks for the useful responses and discussion.

I agree that this is not an RPL issue per-se. Still, I'd like to clarify my
point.

I'm not looking to do any special thing in RPL to support this. All routing
algorithms (not just RPL) would suffer equally from not being prioritized
over regular data frames.

There are methods by the underlying link layers that provide priorities and
QoS (802.11e, for example).

I was looking for a recommendation in the RPL spec for signaling to those
link layers that RPL messages is of higher priority than regular data
packets.

Since this problem is generic to all routing and maybe other ICMP messages,
maybe a more generic pointer exists in another RFC? Are the leads that Alex
provided correct?

Thanks,
Yoav

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Aug 2010 10:57:48 +0200

Hi Yoav:

There is a well-established practice, that's underlined in RFC 4594:

3.1.  Current Practice in the Internet

   Based on today's routing protocols and network control procedures

   that are used in the Internet, we have determined that CS6 DSCP value

   SHOULD be used for routing and control and that CS7 DSCP value SHOULD

   be reserved for future use, potentially for future routing or control

   protocols.  Network administrators MAY use a Local/Experimental DSCP;

   therefore, they may use a locally defined service class within their

   network to further differentiate their routing and control traffic.

It is implicitly the expectation that all RPL messages will be using CS6
(110000).

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Ben-Yehezkel
Sent: Thursday, August 05, 2010 6:19 AM
To: ROLL WG
Subject: [Roll] higher priorities to RPL messages

Hi,

Question to the group:

If there's a high congestion of data traffic in the network, it could
slow down or in some cases of link layers even completely disable the
RPL messages from being transmitted altogether.

Thanks,

Yoav