Subject: SCTP for MANETs

From: "Phil Neumiller" <[email-masked]>
Date: Tue, 11 Dec 2001 18:08:43 -0500

Hi,

I am working on a draft for SCTP in MANETs.  I have by no means finished it.
There appears
to be interest on the list since at least five people have sent me their
Email or ideas.  Here are
some of my own preliminary thoughts on how MANETs could benefit from SCTP.
Perhaps
we can get some more comments on the list about using SCTP in/for ad hoc
networks.  SCTP
could easily be transported over ad hoc networks, but I don't think that is
the important point.
What needs to be carefully examined is how you can use SCTP as a tool or aid
in the construction
of ad hoc networking protocols.

NOTE:  In my heart of hearts I would like to see MANET and MIP ultimately go
away.  I believe
there is a unified NG IP routing protocol that will treat fixed and mobile
network elements in a
very similar way and that mobility will be implicit to the global Internet
itself (this will probably occur
when Quantum Mechanics and Relativity have been unified).    So in the mean
time...

... it might be nice to examine how route advertisements and flooding and
other ad hoc things
could benefit from SCTP.  The following thoughts are pretty raw so please
comment constructively.

o Message boundary preservation.

SCTP preserves applications' message-framing boundaries by placing messages
inside one or
more SCTP data structures, called chunks. Multiple messages can be bundled
into a single
chunk, or a large message can be spread across multiple chunks.

+ Message Boundary Preservation uses in MANETs

This could be very useful in ad hoc networks to prioritize route
advertisements and or handoff
messages between nodes that have formed an SCTP association.   This could
also be useful
for providing some relatively crude forms of QoS.

There is no need to bundle meta data or piggy back with SCTP, since this is
built in, i.e. just
use a different chunk.  The overhead packets can be carried by the
pre-established stream
associations.

o No "head-of-line" blocking.

SCTP eliminates the head-of-line blocking delay that can occur when a TCP
receiver is
forced to resequence packets that arrive out of order because of network
reordering or
packet loss.

+ "Head-of-line" in MANETs

This could be extremely useful in MANETs where pseudo-stationary virtual
circuits are
created with SCTP associations over multiple routes. Packet ordering is a
problem that
is addressed differently in different implementations.  SCTP handles it very
nicely.

o Multiple delivery modes.

SCTP supports several modes of delivery including strict
order-of-transmission (like
TCP), partially ordered (per-stream), and unordered delivery (like UDP).

It seems to me that this could be used as a from of traffic aggregation in
ad hoc networks,
but I am still fuzzy on this..

o Multihoming support.

SCTP sends packets to one destination IP address, but can reroute messages
to an
alternate if the current IP address becomes unreachable.

+  THIS IS REALLY IMPORTANT.  If some nodes are pseudo stable, they can
function as if they were fixed routers but have reliable paths between them,
i.e. if
one of the wireless routers dies, another path is taken almost immediately
without
any need for end-to-end detection of the outage.  You can think of this as
"route
diversity" thus it greatly enhances the reliability of ad hoc networks.
This provides
efficient "self healing" for ad hoc networks.

o TCP-friendly congestion control.

SCTP employs the standard techniques pioneered in TCP for congestion
control,
including slow-start, congestion avoidance, and fast retransmit.  SCTP
applications
can thus receive their share of network resources when coexisting with TCP
applications.

+ Also, SCTP has Path MTU discover and flexible cwnd sizing.

o Selective acknowledgments.

SCTP employs a selective acknowledgment scheme, derived from TCP, for packet
loss
recovery.  The SCTP receiver provides feedback to the sender about which
messages
to retransmit when any are lost.

+ Overhead in ad hoc networks can be avoided with the SACK.

o User data fragmentation.

SCTP will fragment messages to conform to the maximum transmit unit (MTU)
size
along a particular routed path between communicating hosts. This function is
described
in RFC 1191 and is optionally employed by TCP/IP to avoid the performance
degradation that results when IP routers have to perform fragmentation.

+ Route updates could be all different sizes and be sent over all kinds of
different links.
   SCTP provides a scalable way to get them from point to point without
worrying about
   parsing and MTU limits all over the network.

Heartbeat keep-alive mechanism. SCTP sends heartbeat control packets to idle
destination
addresses that are part of the association. The protocol declares the IP
address to be
down once it reaches the threshold of unreturned heartbeat acknowledgments.

+ This is really important.  It give the wireless router the ability to
quickly switch routes
WITHOUT BREAKING THE END-TO-END STREAM associations!

o DOS protection.

To mitigate the impact of TCP SYN flooding attacks on a target
host, SCTP employs a security "cookie" mechanism during association
initialization.

+ This comes for free.  It can surely be used in ad hoc networks.

For more information see Randy and Qiaobing's new Book (Addison Wesley)
"Stream Control Transmission Protocol - reference guide).

Also see http://computer.org/internet/v5n6/w6wire.htm

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 14 Dec 2001 10:04:30 -0800

Hello Phil,

Phil Neumiller wrote:

> in the construction of ad hoc networking protocols.

I'm not intimately familiar with SCTP, but insofar as one node would
have to establish a connection with another node before message data
could be transacted, I think SCTP is a poor choice for control messages.
If SCTP has a "UDP with retransmission" choice, I would be happier.

> away.  I believe there is a unified NG IP routing protocol that will treat
> fixed and mobile network elements in a very similar way and that mobility
> will be implicit to the global Internet itself

I think so too.  This actually has been part of my motivation for
continuing with AODV.  I truly believe that loop-free on-demand
Distance-Vector routing is a _very_ scalable and economical
alternative for arbitrary routing purposes -- and, here, arbitrary
explicitly _includes_ ad hoc.

>                                    (this will probably occur
> when Quantum Mechanics and Relativity have been unified). 

I thought Hawking's work did this, especially regarding the way that
subatomic particles leak from black holes.

>                The following thoughts are pretty raw so please
> comment constructively.

> receiver is forced to resequence packets that arrive out of order because
> of network reordering or packet loss.
> 
> This could be extremely useful in MANETs where pseudo-stationary
> virtual circuits are created with SCTP associations over multiple
> routes.  Packet ordering is a problem that is addressed differently
> in different implementations.  SCTP handles it very nicely.

I gather this is mainly targeted for data streams, not control messages...?

> to an alternate if the current IP address becomes unreachable.
> 
> i.e. if one of the wireless routers dies, another path is taken almost
> immediately without any need for end-to-end detection of the outage.
> You can think of this as "route diversity" thus it greatly enhances the
> reliability of ad hoc networks. This provides

There is a huge difference between multi-homing and route diversity,
generally speaking.  However, if you meant to use the route diversity
by assigning different routes to different IP addresses of the
_same destination_, then I would agree that this is an interesting
possibility.  It seems to me that it would be most useful if the
multiple IP addresses were associated with different media interfaces.

> size along a particular routed path between communicating hosts. This
> function is described in RFC 1191 and is optionally employed by TCP/IP
> to avoid the performance degradation that results when IP routers have
> to perform fragmentation.
> 
> different links.  SCTP provides a scalable way to get them from point to
> point without worrying about parsing and MTU limits all over the network.
> 
> Heartbeat keep-alive mechanism. SCTP sends heartbeat control packets to
> idle destination addresses that are part of the association. The protocol
> declares the IP address to be down once it reaches the threshold of
> unreturned heartbeat acknowledgments.
> 
> quickly switch routes WITHOUT BREAKING THE END-TO-END STREAM associations!

Is this all part of the same bullet item, or did you mean to have two
bullet items?

For route updates, maybe it isn't so applicable to on-demand systems.
For keep-alives, I think more work is needed, but this behavior would
have to be heavily moderated, to the point of being eliminated when
there is actual traffic.  Or maybe SCTP already does this.  But then
some applications would not care.  Maybe the route between two endpoints
would only have the heartbeat mechanisms if there are nonzero SCTP
transport connections between them.

> + This comes for free.  It can surely be used in ad hoc networks.

Agreed, but I don't think it plays directly into topology maintenance,
and I don't see the "ad-hoc" specific nature of the benefit.

Regards,
Charlie P.

PS. I realigned your text to make it look better on my screen...

---

From: [email-masked]
Date: Tue, 18 Dec 2001 07:49:09 -0500 (EST)

Hi Phil,

> efficient "self healing" for ad hoc networks.

There is a *much better* alternative to the type of "route diversity" that
you have described above (BTW, I refer to the "route diversity" that you
have described as "Alternate Path Routing (APR)").

What I am refering to is the "Multi-Path Routing (MPR)" scheme, in which 
you continuously distribute the traffic across multiple paths, rather 
than using the "stand-by" paths when the primary path fails. As paths fail,
the "active path set" is continuously updated with newly discovered paths.
The MPR scheme is based on Diversity Coding and its extensions. It results
in a significant improvement for route stability in the presence of frequent
topological changes. Here are two references to the MPR scheme (a full
journal paper has also been submitted and we will be happy to send a
pre-print once it is accepted):

* A.Tsirigos and Z.J. Haas, "Multipath Routing in the Presence of
  Frequent Topological Changes," IEEE Communications Magazine, November
  2001, vol.39, no. 11, pp. 132-138.

* A.Tsirigos, Z.J. Haas, and S. Tabrizi, "Multipath Routing in Mobile Ad
  Hoc Networks or How to Route in the Presence of Topological Changes,"  IEEE
  MILCOM'2001, Tysons Corner,VA, October 28-31, 2001 

Zygmunt.
==-=-=-==-=
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Prof. Zygmunt J. Haas                    tel: +1-607-255-3454
Wireless Networks Laboratory		                  
School of Electrical Engineering         fax: +1-607-255-9072 
Cornell University
323 Frank Rhodes Hall			 e-mail: [email-masked]
Ithaca, NY 14853			 
U.S.A                             http://www.ee.cornell.edu/~haas/wnl.html
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-

---

From: "qi xue" <[email-masked]>
Date: Tue, 18 Dec 2001 13:06:33 -0500

Hi, Zygmunt

> topological changes.

I am curious how do you guarantee the delivery order and resolve the
potential collisions
between data pkts in two different paths which are of the same flow?
In addition, the multiple paths need to be far away enough from each other
in order to
avoid colliding all the way to the destination. (which means more diversity
of end-to-end delay)

Qi Xue

---

From: [email-masked]
Date: Tue, 18 Dec 2001 20:53:53 -0800

> the "active path set" is continuously updated with newly discovered paths.

This is precisely the sort of thing we had in mind when we decided to give each 
node running TBRPF the option of reporting additional topology information, up to 
the full network topology.  For example, each node can compute and report a 
biconnected subgraph, which will provide two disjoint paths to each destination.  
(Actually each node only needs to report a relatively small part of this subgraph on average.)

Unfortunately, OLSR cannot guarantee that each node will know of two disjoint paths
to each destination even if the graph is biconnected, since the graph formed by
MPR (multipoint relay) links need not be biconnected.  

In this sense, TBRPF *does* allow the use of MPR (multipath routing). :-)

Richard

---

From: [email-masked]
Date: Wed, 19 Dec 2001 09:42:20 -0500 (EST)

Hi Qi,

The delivery order is guaranteed by simple sequence numbers. I am not sure
what do you mean by "resolving potential collisions" - any collisions
would be resolved by the specific MAC that is implemented in the network.
All that is assumed by MPR is that there are a number of paths with some
parameters ...

Intuitively, the more "disjoint" the paths are, the better performance you
can expect. (So that a failure of one path does not mean that other paths
are down as well.) However, suprisingly, some amout of correlation between
the paths is possible without hurting the performance. This is demonstrated 
in the paper.

Best,

Zygmunt.
===--=-==-==