Subject: Re: uni-directional links

From: Nitin H Vaidya <[email-masked]>
Date: Thu, 4 Jan 2001 10:09:54 -0600 (CST)

To add to Philippe's comments below, it may be hard to justify
using unidirectional links except in some special circumstances.

Using unidirectional links could be inefficient. Consider the
network shown below:

   A -----> B ------ C

(A,B) link is unidirectional and (B,C) link is bidirectional.
In this case, it may be difficult for node A to defer to an on-going
transmission from B to C (since A may not hear B due to unidirectional
nature of AB link). Thus, A could try transmitting a packet to B,
while B is busy forwarding the previous packet from A (or busy with
some other transmission).
So, there is a good probability that packets transmitted by A
would not be received by B.

Also, using unidirectional links can aggravate unfairness in
accessing the wireless channel. Again consider the network above.

Let us assume that both nodes A and C want to send packets
to node B. Assume a MAC protocol similar to 802.11.
In this case, when B is receiving packets from A, C can/will
defer to that transmission, allowing the transmission to
complete successfully. On the other hand, transmission from
C to B will often fail due to interference from A (node A does
not know to defer to the C->B transmission).
This could result in a very unfair allocation of bandwidth to
nodes A and C.

Such unfairness can, in fact, occur even when we only use
bi-directional links. However, using unidirectional links
makes the problem worse.

An issue closely related to unfairness is congestion control.
When transmitting on unidirectional links, such as link (A,B),
it might be hard to take into account the level of congestion
at node B, making congestion control at the MAC layer less
effective.

I guess, in special cases, using unidirectional links
may make sense, particularly when no other route is available
(or, as in case of dedicated link, it may be known that the
unidirectional link does not interfere with other transmissions,
so issues of fairness/congestion may go away).

As has been pointed out though, protocols that rely on bidirectional
links should be provided some mechanism to determine which links are
bidirectional.

Cheerio.

- nitin

  >> From [email-masked] Thu Jan  4 09:19:43 2001
  >> 
  >> Happy millenium for everybody!
  >> 
  >> It is not clear whether the question is:
  >> 
  >> Which protocols function correctly with bi_D links but may not function
  >> correctly in presence of uni_D links?
  >> 
  >> for example, AODV, DSR, if some amendments are not introduced.
  >> 
  >> or:
  >> 
  >> Which protocols function correctly in presence of uni_D links but route
  >> only on bi_D links?
  >> 
  >> for example FSR, OLSR, TBRPF... 
  >> 
  >> Added to this issue there is also the issue about the link layer which is
  >> in general bi-D link oriented like in IEEE802.11, Hiperlan, Bluetooth. In
  >> this case routing on bi-D links is mandatory. I don't know uni_D link
  >> oriented MAC but in this case the link control is either unreliable or very
  >> complicated. 
  >> I think DSR has something very complicated in case of uni_D, and some
  >> feature of route caching would probably need to be disabled. In presence of
  >> some uni_D links together with a bi_D MAC there are also serious sources of
  >> flaws. 
  >> 
  >> Philippe
  >>

---

From: Kenneth Brayer <[email-masked]>
Date: Thu, 04 Jan 2001 12:17:17 -0800

For the military application, which is my area of interest, it is very
common (actually highly likely) that links will be unidirectional. The
fact that A can hear B on an HF or UHF radio circuit does not mean that
B can hear A on that circuit. So a path from A to B may be reversed by a
path from B to C and one from C to A. Thus for military users protocols
that work unidirectional are needed and those that work uni- and also
bidirectional are considered to have extra value. Bidirectional only may
be useless.

Kenneth Brayer
The MITRE Corporation/
Air Force Electronic Systems Center
Bedford, MA