Subject: [manet] DLEP discussion related to credit window per TDMA neighbor

From: [email-masked]
Date: Thu, 18 Oct 2012 17:05:47 -0500

Sorry about delay, but am finally catching up on several weeks of manet 
emails (whew!)

On Tue, 4 Sep 2012 (was Subject Thread "Re: [manet] I-D Action: 
draft-ietf-manet-dlep-03.txt") , "Stan Ratliff" wrote:
>
> On Sep 4, 2012, at 9:17 AM, Henning Rogge wrote:
> >
> > If I understand DLEP right it handles a credit window per neighbor. 
How
> > do we handle the common usecase where we have a radio with a "sender
> > window", which means we have credits for sending data, but not to a
> > specified receiver.
>
> I've never seen, nor dealt with, such a device, and we have the credit 
> windowing of RFC4938/RFC5578 deployed with multiple radios.  What you 
> imply is a credit scheme that would exist from router to modem, and 
> the 03 DLEP specifically precludes that. 
> 
> > Lets say our radio (because of some TDMA waveform) has an outgoing
> > credit window of 1000 bytes.
> 
> Sorry, but I can't envision a TDMA radio that doesn't have a "specified 
> receiver". After all, isn't that the point of TDMA? That being, that 
> *someone* "out there" is listening at the time you're sending? Now, 
> there could be a broadcast/multicast slot, but that would be handled in 
> DLEP by using the correct MAC address (e.g. for the broadcast/multicast) 

> and creating a neighbor.

FYI, many mobile broadcast networking radios and waveforms that I work 
with, dynamically assign TDMA time slot for one transmitter to be able to 
talk to multiple receivers (neighbors). So all of the receivers are 
listening in that time slot, but it is the transmitter that decides which 
neighbors to transmit to for each time slot based upon what packets are in 
its transmit queues. So a particular time slot could just include 
packet(s) for just a single receiver or it could include packet(s) 
intended for multiple receivers.  The transmitter looks at the intended 
receiver list to select the actual transmission parameters on a per 
transmission basis.  I.e., the transmitter picks the appropriate coding 
(data rate) and power to reach the intended receivers with the appropriate 
quality of service.

These broadcast wireless networks are multihop and perform wireless 
routing below IP (analogous to "ethernet bridging (routing) below IP"). 
Thus, the transmitter can even decide whether to transmit at a high data 
rate to a neighbor node and let that neighbor node relay (transmit) at a 
high data rate to the destination (or another relay node) instead of 
transmitting at a low data rate directly to the destination (or another 
relay node) depending upon which provides the best overall wireless 
network performance.  Network coding (whether for unicast or multicast) is 
similar.

So in general, the payload capacity per TDMA transmission can change 
depending upon the set of intended receivers for that TDMA transmission.

As you can image, flow control for such networks is complicated. In 
general, there have been different approaches depending upon the desired 
end-to-end QOS. For example, constant bit rate traffic (CBR) QOS is 
easiest to manage and maps well to a credit window per destination 
(whether unicast or multicast. Elastic watermarks, rate control with 
hysteresis, and other approaches are used for other QOS types.

In general, I think that a credit scheme can work with most of these 
multihop broadcast networks as long as you define the neighbor as the IP 
neighbor and don't care if that IP neighbor is one, two, or N wireless 
relay hops away.

Jim Stevens

---

From: Teco Boot <[email-masked]>
Date: Fri, 19 Oct 2012 08:13:47 +0200

Op 19 okt. 2012, om 00:05 heeft [email-masked] het volgende geschreven:

> 
> Sorry about delay, but am finally catching up on several weeks of manet emails (whew!) 
> 
> On Tue, 4 Sep 2012 (was Subject Thread "Re: [manet] I-D Action: draft-ietf-manet-dlep-03.txt") , "Stan Ratliff" wrote: 
> > 
> > > If I understand DLEP right it handles a credit window per neighbor. How
> FYI, many mobile broadcast networking radios and waveforms that I work with, dynamically assign TDMA time slot for one transmitter to be able to talk to multiple receivers (neighbors). So all of the receivers are listening in that time slot, but it is the transmitter that decides which neighbors to transmit to for each time slot based upon what packets are in its transmit queues. So a particular time slot could just include packet(s) for just a single receiver or it could include packet(s) intended for multiple receivers.  The transmitter looks at the intended receiver list to select the actual transmission parameters on a per transmission basis.  I.e., the transmitter picks the appropriate coding (data rate) and power to reach the intended receivers with the appropriate quality of service. 
> 
> These broadcast wireless networks are multihop and perform wireless routing below IP (analogous to "ethernet bridging (routing) below IP"). Thus, the transmitter can even decide whether to transmit at a high data rate to a neighbor node and let that neighbor node relay (transmit) at a high data rate to the destination (or another relay node) instead of transmitting at a low data rate directly to the destination (or another relay node) depending upon which provides the best overall wireless network performance.  Network coding (whether for unicast or multicast) is similar. 
> 
> So in general, the payload capacity per TDMA transmission can change depending upon the set of intended receivers for that TDMA transmission. 
> 
> As you can image, flow control for such networks is complicated. In general, there have been different approaches depending upon the desired end-to-end QOS. For example, constant bit rate traffic (CBR) QOS is easiest to manage and maps well to a credit window per destination (whether unicast or multicast. Elastic watermarks, rate control with hysteresis, and other approaches are used for other QOS types. 
> 
> In general, I think that a credit scheme can work with most of these multihop broadcast networks as long as you define the neighbor as the IP neighbor and don't care if that IP neighbor is one, two, or N wireless relay hops away. 

You described an advanced media access mechanism, which looks familiar to what I have worked with. Such is not easy to abstract to a flow control mechanism. For example, there must be flow control for each dscp codepoint. With multi-hop sub-IP paths, the flow control shall act on bottlenecks on radio's not directly connected to the router. And there could be nodes without a router, were all QoS handling is on the radio. That's why I don't see flow control as a preferred solution. Handling QoS on the radio's can easily outperform flow control for multiple reasons. Radio's I work with just do that.

I don't say I cannot see any advantage. I just say it doesn't belong in the IETF DLEP proposed standard.

Teco

> 
> Jim Stevens_______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Oct 2012 10:41:50 +0200

On 10/19/2012 08:13 AM, Teco Boot wrote:
> You described an advanced media access mechanism, which looks
> familiar to what I have worked with. Such is not easy to abstract to
> a flow control mechanism. For example, there must be flow control for
> each dscp codepoint. With multi-hop sub-IP paths, the flow control
> shall act on bottlenecks on radio's not directly connected to the
> router. And there could be nodes without a router, were all QoS
> handling is on the radio. That's why I don't see flow control as a
> preferred solution. Handling QoS on the radio's can easily outperform
> flow control for multiple reasons. Radio's I work with just do that.
>

The problem is not only QoS but also buffer management. You either have 
to manage the buffer exactly before the bottleneck (in this case the 
radio, because its slower than the ethernet) or you have to move the 
bottleneck (with flow control for example).

Otherwise you get lots of latency.

Its difficult to move the "buffer management" rules from the router to 
the radio, so restricting the routers output to the radio (which moved 
the bottleneck to the router) is a good strategy.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Teco Boot <[email-masked]>
Date: Fri, 19 Oct 2012 11:16:30 +0200

Op 19 okt. 2012, om 10:41 heeft Henning Rogge het volgende geschreven:

> The problem is not only QoS but also buffer management. You either have to manage the buffer exactly before the bottleneck (in this case the radio, because its slower than the ethernet) or you have to move the bottleneck (with flow control for example).
> 
I don't get this. The QoS packet dispatch function shall handle congestion, in that flows that cannot tolerate large latency doesn't suffer from such. And yes, bufferbloat is something that needs to be fixed. 

> 
> Its difficult to move the "buffer management" rules from the router to the radio,
Why? Is it more difficult than distributing policies to routers? Cannot be so. Not in my designs.

> so restricting the routers output to the radio (which moved the bottleneck to the router) is a good strategy.
Only for radio's that cannot provide basic QoS services. And it introduces other problems, e.g. it only works for 1-hop L2 networks so it doesn't work well in the scenario Jim Stevens described.

So the options are: fix QoS on radio or, IMHO 2nd best, transfer bottleneck from radio to router.

My suggestion is to separate this from link metric exchange. These are very different functions. 

Teco

> _______________________________________________
> manet mailing list
> [email-masked]