Subject: [manet-dlep-rg] Some considerations for tactical radios

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Fri, 30 Aug 2013 15:48:48 -0400

Hi guys,

I've been working with Martin Duke on helping integrate DLEP into some
tactical radios systems. Below is a few thoughts he put together on
potential areas for new metrics. They span the following considerations:

* Handling of multiple queues at the radio corresponding to various
service levels
* Accommodating link-layer routing schemes in the radio
* Topology Management: for ad-hoc point-to-point (e.g. Narrow-beam
directional) radios, allows the router to use its knowledge of traffic
demand to specify which links to form
* Extremely fine-grained reporting of latency

1. QUEUE RESOLUTION
===================

One issue with flow control is that there is not, in fact, a single queue
in many advanced radios. There are instead multiple queues to serve
different QoS objectives. With a single flow control credit account, this
can create head-of-line blocking problems.

For instance, if a radio can grant a maximum of 50 packet-size credits due
to its queue size(s), and 50 low-priority packets are currently in a
queue, then as long as the radio delays delivery of those low-priority
packets, flow control blocks delivery of high-priority packets even though
the high-priority queue.

The most technically comprehensive alternative is to create a separate
flow control "account" for each queue in the radio. This requires
negotiation of the mapping between the TOS byte (assuming there are no
other traffic discriminators!) and these flow control  accounts. We don't
believe there are any fundamental failures inherent with this approach,
but it also strikes us as imposing heavy complexity on both the router and
the interface implementor. That said, if someone has the bandwidth to
devise such a system and think through its implications we would support
the effort.

Failing that, we think a limited number of flow control accounts may do
the trick. We add a one-byte "account index" to all flow-control messages,
which correspond to well-understood behaviors:
Account 0: High-priority latency-sensitive traffic, roughly corresponding
to "Expedited Forwarding."
Account 1: Other latency-sensitive traffic (AF)
Account 2: Everything else
These behaviors are centered on latency, as in our view that's the most
salient impact of head-of-line blocking. That said, we'd certainly be open
to a handful of additional accounts if others foresee a requirement for
them.

Radio DLEP clients would be responsible for aggregating their queue
information into these three accounts, using vendor-specific techniques.
Radios that don't have any queues in one of these buckets (e.g., there is
only one queue for all traffic) can capture that using a "Queue Capacity"
TLV to be exchanged during session start that indicates the capacity of
each of these. We created this TLV to provide more latency resolution but
it also serves to indicate queues/accounts that don't exist:

Queue Capacity TLV: (send in Peer Discovery/Peer Update messages if queues
are shared among neighbors, Neighbor Up/Neighor Update if each neighbor
has dedicated queue space.)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = TBD | Length = 12   |          Queue 0 Size         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Queue 0 Size          |          Queue 1 Size         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Queue 1 Size          |          Queue 2 Size         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Queue 2 Size         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. LINK LAYER ROUTER RESOLUTION
===============================

Many advanced radios have link-layer routing capability. While this
concept sits uneasily with the concept of a radio-to-router interface, it
is easy to envision use cases where either radio or router has the
advanced routing techniques most applicable to the situation. Therefore,
we developed an approach that gives the router enough information to
decide whether or not to leverage these links: the hop count TLV, sent in
Neighbor Up and Neighbor Update messages:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = 0xE2|  Length = 1   |P| Hop Count   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

P	-	Potential Neighbor Bit. If the hop count is greater than 1, AND the
sender's best estimate that it is able to form a direct point-to-point
link given current node positions, it MUST mark this field ë1í. Under all
other circumstances of sender and reachability estimate, this field is
marked ë0í.

Hop Count	-  An unsigned 7-bit integer, the number of RF hops required to
reach the neighbor given existing links. For point-to-point radios, this
is computed using existing links without regard for RF range. If the Hop
Count is greater than 1 but the radio cannot compute the precise value, it
MAY fill in the value 0x7F.

The Potential Neighbor bit is relevant to topology management, where a
router may instruct a directional radio to form a point-to-point link with
a multihop neighbor.

Note that radios have some discretion as to what hop count they report: a
node might be reachable at a low data rate, or high error rate, but the
radio may choose to report it as a multiple-hop neighbor at a higher
data/lower error rate.

3. TOPOLOGY MANAGEMENT

======================

Many TDMA-based directional radio systems have a finite number of time
slot resources to dedicate to links with a large number of potential
neighbors in range. In many directional networking design discussions the
process of selecting actual neighbors from potential neighbors is known as
"topology management."

There are benefits to running this process with awareness of traffic
demand, which makes it natural to run on the router side of the
router-to-radio interface. There are a few new message concepts to realize
this, but perhaps it's best to explain with a narrative.

1) Radio informs router of potential neighbors using the Hop Count TLV
(see previous above) with the "P" bit set to 1 in a Neighbor Up or
Neighbor Update Message.

1a) The radio might also use Maximum Data Rate to report throughput data
for the potential neighbor.

2) In our concept the Resources TLV is recycled to report Time Slot
resources available at the radio, but perhaps others will prefer this to
be a new TLV. This is in a Peer Discovery or Peer Update message.

3) If spare resources are available, the router may request a Hop Count of
1 using a Hop Count TLV in a Link Characteristics Request Message.

4) The radio responds with a Link Characteristics ACK, Resources TLV, and
updated Hop Count TLV when it establishes the link.

Note also that the router can ask for the deletion of a link using a Hop
Count TLV with a value greater than 1 in a Link Characteristics Request;
if successful, this should trigger in update of both hop count and
available resources.

As a final side note, in TDMA systems requesting additional data rate in
accordance with the DLEP standard will generally consume time slot
resources. Using the Resources TLV to report time slots allows the router
to more intelligently manage this resource when askign for links and
bandwidth.

4. ENHANCED LATENCY
===================

Our customer is very interested in fine-grained latency assurances. We
found the combination of a loosely defined Latency TLV and oddly precise
EFT TLV to be redundant and yet not comprehensive. Instead, we propose the
following framework:

1. Replace "Latency" with "Max/Min Latency". This enables routers to
determine if a given path is (a) assured to meet the latency requirements
of a packet, (b) will definitely not meet the requirements, or (c) may or
may not meet the requirements. This enables a suite of experimental but
promising router behaviors. The text we propose for this TLV is as follows:

****

9.XX Max/Min Latency

The Max/Min Latency TLV indicates the limits of expected per-hop
link-layer latency. It does NOT include any delay related to queuing, nor
any delay associated with link-layer retransmission. Radios SHOULD measure
latency from the point at which a packet becomes the next packet to
schedule on the MAC to the point the next-hop receiving radio completes
reception.

Max/Min Latency for neighbors multiple RF hops away SHOULD account for the
multiple hops.

Radios with non-deterministic MAC protocols that do not provide strict
latency bounds SHOULD use the 5% and 95% confidence intervals, unless a
different but nearby value provides a better ìbreak point.î

When link-layer latency varies for various Quality of Service (QoS)
levels, the radio SHOULD report the parameters for a representative
latency-sensitive packet, rather than best-effort flow.

Peer Discovery, Peer Update, Neighbor Up, Neighbor Update, Link
Characteristics Request, and Link Characteristics ACK messages MAY contain
the Max/Min Latency TLV.

Routers MAY request lower latency, or relax a previous request, via a
Max/Min Latency TLV in a Link Characteristics TLV.
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = TBD |  Length = 4   |      Maximum Latency (ms)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Minimum Latency (ms)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Maximum Latency 	- The longest time in ms between a packetís emergence at
the front of its queue to the end of its reception at the neighbor radio,
assuming no link-layer retransmission.

Minimum Latency 	- The shortest time in ms between a packetís emergence at
the front of its queue to the end of its reception at the neighbor radio,
assuming no link-layer retransmission.

***

2. The "Queue Capacity TLV" (introduced in the thread about QoS flow
control) provides a maximum additional delay due to queuing. Although we
believe it's impractical to pass instantaneous queue state around the
network, this allows routers to assess worst-case latencies of a path.

--
Bow-Nan Cheng, Ph.D.
MIT Lincoln Laboratory
Airborne Networks Group
244 Wood St Lexington MA 02420
781-981-4997