Subject: Out of Order

From: Maria Elena Villapol <[email-masked]>
Date: Wed, 17 Nov 1999 17:45:43 +1030

Hi

is it possible that RSVP Messages going from one hop to the next one
arrive out of order?

thank for your help

Maria

--
Maria Elena Villapol
PhD Student
Institute for Telecommunications Research
University of South Australia

email: [email-masked]
       [email-masked]

Web Page: http://www.itr.unisa.edu.au/~maria/index.htm

---

From: David Charlap <[email-masked]>
Date: Wed, 17 Nov 1999 10:45:09 -0500

> is it possible that RSVP Messages going from one hop to the next one

Possible but not likely.  Here are a few scenarios I can think of:

- There's a non-RSVP router between the router sending the message and
  the one receiving the message.  Messages that have the router-alert
  option (like Path) will be slow-path forwarded, while messages without
  router-alert (like Resv) will be fast-path forwarded.  This could
  cause them to be re-ordered.

- If non-RSVP routers are between the sender and receiver, those routers
  might employ some kind of equal-cost multipath routing that sends the
  two packets along different paths.  This could result in out of order
  delivery.

If the sending and receiving router are directly connected, with no
intervening non-RSVP router, I don't think re-ordering is possible.  Of
course, the sending router may not send the messages in the order you
expect, but that's not an out of order delivery situation.

I'm not sure, however, why this kind of reordering would cause a
problem.  Due to RSVP's soft-state nature, a router should be able to
receive messages in any order.  And messages should never be fragmented.

Reorderings that might cause a problem (like Resv before Path) are
logically impossible, since one won't be sent until the other is
received.  (A Resv can't arrive before its Path, since the recipient
won't send the Resv until after it receives its Path.)

-- David

---

From: Ping Pan <[email-masked]>
Date: Wed, 17 Nov 1999 13:38:25 -0500

> > is it possible that RSVP Messages going from one hop to the next one

Yes. It is possible due route changes. Actually, you may run into some
bad conditions if you're not careful with your code.

For example, a router A gets PATH refresh messages from a previous hop
router B. Say, after sending a refresh message, the link goes down. Then
a PATHTEAR arrives to the router B, and is forwarded through a new route
immediately. It is possible that the PATHTEAR gets to the router A
before the PATH refresh message. In the worst case, the router A will
remove the reservation according to PATHTEAR, and restore it after
processing the PATH refresh. 

So in the RSVP implementation, you may want to record the ingress
interface information for each PATH state, and only process the messages
with the correct ingress interface. In this example, you should drop the
PATHTEAR, and let the soft-state to remove the reservation eventually.

- Ping

---

From: Rohit Chhapolia <[email-masked]>
Date: Wed, 17 Nov 1999 17:42:07 -0500

David,

There are some reordering which may create non desirable situations.

For ex. A node sends PATH followed by PATH TEAR and next RSVP hop
receives PATH TEAR followed by PATH. While the intention would be
to clean the Path State, the result would be Path State cleanup
followed by new Path state creation. Of course, there would be no
refresh and this state would timeout finally (self-healing nature
of RSVP) but the network resources would be occupied for this time.

Rohit

-- 
Rohit Chhapolia
Ficon Technology, Inc.
mailto:[email-masked]
http://www.ficon-tech.com

---

From: Graham Cope <[email-masked]>
Date: Thu, 18 Nov 1999 15:40:55 +0000

> bad conditions if you're not careful with your code.

or the protocol?

> processing the PATH refresh.

I guess that there is a similar problem with load balancing (e.g.
equal-cost multipath routing as mentioned by  David Charlap).

What guarantee is there that:

1) Actual traffic goes out on the same egress i/f as the PATH message?
2) The PATHTEAR goes out on the same egress i/f as the PATH message?

If you're doing load-balancing then surely it is necessary to duplicate the
PATH messages across each route, and the corresponding RESV meassges will
need to be duplicated in the reverse direction? Interesting question there
as to how to split the Flowspec (e.g. half the traffic split 2-ways)....

Regarding PATHTEAR, RFC 2205 states that the IP desitination address of the
PATHTEAR is the session dest address. This may not go out on the same i/f
as the PATH message. If instead it routed on N-HOP (from the RSB(s)) then
it would.

Graham

---

From: David Charlap <[email-masked]>
Date: Thu, 18 Nov 1999 13:29:00 -0500

> equal-cost multipath routing as mentioned by  David Charlap).

I should hope that anybody doing equal-cost multipath routing on an RSVP
box designs it with enough common sense so that a signle flow always
follows the same path.

Otherwise, it makes the concept of reservation along the path difficult
to impossible.  (You'd have to reserve bandwidth along both paths, which
is wasteful)

> 2) The PATHTEAR goes out on the same egress i/f as the PATH message?

If equal-cost multipath isn't being done, then these guarantees can be
made until the routing table changes.  At that point, the data would
follow the new path.

The RSVP router should detect the routing table change and issue a new
Path message if the data path is changed as a result.  The old path
would be left to time out, I think.

> If you're doing load-balancing then surely it is necessary to
> duplicate the PATH messages across each route, and the corresponding
> RESV meassges will need to be duplicated in the reverse direction?

If a single session could be routed along multiple paths, yes.

The few equal-cost multipath scenarios I've seen take precautions so
that a single flow always takes the same path.  Multiple paths would
only be used for multiple flows.  This is done because out-of-order
delivery causes TCP to detect it as network congestion, causing it to
unnecessarily throttle transmission rates.

Assuming that this is done, we shouldn't be too concerned about it.

I only mentioned it in the context of a non-RSVP router between two RSVP
routers.  Such a router probably doesn't know about RSVP packets, so it
is probably going to treat them as separate entities (like UDP
packets).  In other words, it may deliver RSVP packets out of order, but
it would probably not deliver data packets out of order.

-- David

---

From: Maria Elena Villapol <[email-masked]>
Date: Fri, 19 Nov 1999 11:36:42 +1030

Thank everybody for  all given RSVP scenarios where messages may arrive
out of order.Maria