Subject: Re: uni-directional links

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

>> From [email-masked] Thu Jan  4 11:21:37 2001
  >> 
  >> 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.

I would agree with that ... when links are highly likley to be
unidirectional, one may not have much choice but to somehow use
them. I guess what may be best is a protocol that works with
both uni- and bi-directional links, but uses bi-directional
links preferentially.

- nitin

  >> 
  >> Kenneth Brayer
  >> The MITRE Corporation/
  >> Air Force Electronic Systems Center
  >> Bedford, MA
  >> 
  >> Nitin H Vaidya wrote:
  >> > 
  >> > 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 13:46:16 -0800

Nitin
I agree.
Ken