Subject: [manet] Do MANET radios require collision detection?

From: "Scott C. Lemon" <[email-masked]>
Date: Tue, 2 Jul 2002 17:55:31 -0600

Hello again,

I appreciate all of the responses to my other questions/comments ... I'm still digesting and reading and appreciate all of the expertise being shared on this list.  I'm sure that as I follow this conversation more, I'll become more aware of the various topics and issues ...

One area that I wanted to ask a question or two is related to current commercial radios.  It appears that most people are using 802.11b (or maybe even "a") for their MANET work.  I too use 802.11b, however the distance is very limiting.

I have recently been working with a company to develop an alternative radio for my purposes, and am now interested in the radio requirements to work with the software that is currently being used with the 802.11b cards.

My specific question is if most of these MANET protocols and software require collision detection in the radio on transmission?  We almost have completed a prototype of a radio that can be serially or USB attached, that would provide lower bitrates (~115kbps), however much longer distances (1+ miles).  In the current prototype, the radio will just transmit without any collision detection.  Will higher layers in the stack/software perform retries, etc.?  I know that TCP handles this for its streams, however it appears that some of the MANET protocols/software might be UDP or even lower level ...

Again ... this might not be exactly the right question due to my new understanding of some of the MANET software being developed ... am I right to be concerned about this?

Thank you in advance!

Scott C. Lemon
HumanXtensions L.L.C.
http://www.HumanXtensions.com
http://the.Inevitable.Org/anism

   "People often talk about it being the journey, not the destination.
        Consider the possibility that there is no destination ...
                    that in life there is only journey!"

---

From: David Young <[email-masked]>
Date: Tue, 2 Jul 2002 20:05:03 -0500

I write this response from imprecise recollections of TCP and 802.11,
so someone please correct me if I write something wrong.

Collision detection is not really possible in a radio network like it is
in a wired network because of the hidden terminal problem. Say radios A
and C cannot hear each other, but B can hear both.  If they both transmit
to B at once, a collision will occur at B's receiver, but neither A or
C will hear it. The only indication for a collision is the lack of an ACK.

TCP will handle lost segments, true, but today's implementations assume
links with few bit errors, and so a lost segment is interpreted as network
congestion, not mis-transmission. A TCP implementation will actually
slow its transmissions when segments are lost. This is exactly the wrong
thing to do in a wireless network; because bits are received in error
very often, a lost segment most likely means you should just re-transmit,
and fast.  So a wireless MAC protocol like 802.11's tries to "simulate"
(shall we say) a more reliable medium by breaking a frame into fragments
(so that if a portion of a frame is clobbered on the air, the whole frame
need not be retransmitted) and sends those.  Each fragment requires the
receiver's timely acknowledgement or it is resent. The 1999 802.11 draft
standard has a good discussion of this; you can download it from IEEE
for free.

Most applications using datagrams will tolerate lost datagrams. If not,
they will provide their own retry mechanism. I imagine retries will be
spaced very far apart, however, because the implementors of datagram
retries will make similar assumptions as TCP implementors.

So, to answer your question, if you will use a standard TCP
implementation, your radio interface should protect the IP layer from
common-case transmission errors so that TCP will not needlessly back-off
on transmissions, and datagram apps will not invoke overly-long retransmit
delays.

Dave

-- 
David Young             OJC Technologies
[email-masked]     Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: David Young <[email-masked]>
Date: Tue, 2 Jul 2002 20:05:03 -0500

Dave

---

From: Yang Xiao <[email-masked]>
Date: Tue, 2 Jul 2002 21:43:02 -0700 (PDT)

Dave

Well, I know little about MANET. If I am wrong, please let me know.

--- David Young <[email-masked]> wrote:

> Collision detection is not really possible in a radio network like it
> is in a wired network because of the hidden terminal problem. Say 
> radios A and C cannot hear each other, but B can hear both.  If they
> both transmit to B at once, a collision will occur at B's receiver, 
> but neither A or C will hear it. The only indication for a collision
> is the lack of an ACK.

Even though IEEE 802.11 does have the hidden terminal problem, the
intent of 802.11 is to use indoor and assume that at most time, all the
nodes are in the range. Therefore, IEEE 802.11 considers very little
about the hidden terminal problem. Exceptions like: RTS/CTS and using
lower data rate to transmit control frames can help a little bit on
hidden terminal problem.

> TCP will handle lost segments, true, but today's implementations
> assume links with few bit errors, and so a lost segment is 
> interpreted as network
> slow its transmissions when segments are lost. This is exactly the
> wrong thing to do in a wireless network; 
> because bits are received in error
> and fast.  

This is well known. Not particular for TCP over Wireless LAN, but TCP
over any wireless Medium. I guess that the problem mostly like being
TCP, but not lower layers (wireless networks).

> So a wireless MAC protocol like 802.11's tries to
> "simulate"

Such a conclusion is not correct. The reliable transmission is achieved
by using ACKs. Fragmentation is not required by the standard, and its
threshold can be very large.

> on transmissions, and datagram apps will not invoke overly-long

Do you really think that PHY layer (radio) should have so much
knowledge about higher layers (TCP/IP)?

> > One area that I wanted to ask a question or two is related to
> current commercial radios.  It appears that most people are using
> 802.11b (or maybe even "a") for their MANET work.  I too use 802.11b,
> however the distance is very limiting.

I would like to claim that the goal of IEEE 802.11 standards and
implementations is not for MANET. Many people in MANET choose 802.11
because 802.11 is available and it is difficult to find a better one.

> > My specific question is if most of these MANET protocols and
> software require collision detection in the radio on transmission? 

I guess that collision detection is a MAC/PHY issue, whereas MANET is a
higher layer than MAC. Collision detection should not be an issue for
MANET.

Yang

> We almost have completed a prototype of a radio that can be serially
> or USB attached, that would provide lower bitrates (~115kbps),
> however much longer distances (1+ miles).  In the current prototype,
> the radio will just transmit without any collision detection.  Will
> higher layers in the stack/software perform retries, etc.?  I know
> that TCP handles this for its streams, however it appears that some
> of the MANET protocols/software might be UDP or even lower level ...
> > 
> > Again ... this might not be exactly the right question due to my
> new understanding of some of the MANET software being developed ...
> am I right to be concerned about this?
> > 
> > Thank you in advance!
> > 
> > 
> > Scott C. Lemon
> > HumanXtensions L.L.C.
> https://www1.ietf.org/mailman/listinfo/man

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

---

From: Yang Xiao <[email-masked]>
Date: Tue, 2 Jul 2002 21:43:02 -0700 (PDT)

Dave

Yang

---

From: David Young <[email-masked]>
Date: Wed, 3 Jul 2002 02:27:07 -0500

> threshold can be very large.

  I did not say as much in the rest of the snipped sentence? =) I think
  we agree.

  Do you disagree that fragmentation is important where TCP is concerned?
  I expect short burst of bit errors on the wireless medium.  Long-ish
  frames sent whole with just a few bit errors will take twice the time
  or more to reach their destination because they will be retransmitted
  whole, too. Seems like the delay of retransmitting in toto will often
  provoke TCP to back off from sending. However, if a long-ish frame
  is sent in fragments, you can retransmit one or two fragments and TCP
  hasn't an inkling.

> knowledge about higher layers (TCP/IP)?

  In the short term, it doesn't matter what I think, because I cannot
  retroactively change TCP implementations. =(

  To answer your question, I don't know yet what a stream protocol that
  is suited to unreliable media (or mixed media) will look like, so if
  the PHY/MAC will take care of that for me, I will not protest.

  What do you think?

> because 802.11 is available and it is difficult to find a better one.

  Agreed.

Dave

---

From: David Young <[email-masked]>
Date: Wed, 3 Jul 2002 02:27:07 -0500

What do you think?

  Agreed.

Dave

---

From: Yang Xiao <[email-masked]>
Date: Wed, 3 Jul 2002 09:08:52 -0700 (PDT)

Dave,

--- David Young <[email-masked]> wrote:

> Do you disagree that fragmentation is important where TCP is
> concerned? I expect short burst of bit errors on the wireless medium.

> Long-ish frames sent whole with just a few bit errors will take twice

> the time or more to reach their destination because they will be
> retransmitted whole, too. Seems like the delay of retransmitting in 
> toto will often provoke TCP to back off from sending. However, if a 
> long-ish frame is sent in fragments, you can retransmit one or two 
> fragments and TCP hasn't an inkling.

Sure, fragmentation can help packets go though wireless medium. 

Assume that we are discussing a pure ad hoc network in which no wired
network is involved. Under such an assumption, TCP should adjust itself
and set the re-transmission timer much longer than usual. I believe
that TCP is the place to be adjusted, but not wireless MAC or PHY.

>   retroactively change TCP implementations. =(

Why not? I believe that TCP implementations should be the right place
to change.

> To answer your question, I don't know yet what a stream protocol
> that is suited to unreliable media (or mixed media) will look like,
so
> if the PHY/MAC will take care of that for me, I will not protest.
>
> What do you think?

If PHY/MAC can, that is great. However, it is not easy or maybe not
worthwhile taking the efforts.

Let's make an analogy as follows. TCP takes care the ordering and
reliable transmission of a stream over IP, but IP does not do these.
One reason is that IP is not a stream protocol, and TCP is. Therefore,
TCP needs to take care of it's own business. The similar thing happens
for TCP over WLAN. WLAN can not take care anything about stream
protocol, which is TCP's business. In order words, it is none of WLAN's
business.

Regards

Yang

---

From: Yang Xiao <[email-masked]>
Date: Wed, 3 Jul 2002 09:08:52 -0700 (PDT)

Dave,

so

Regards

Yang