Subject: Re: RSVP PathError and ResvError messages

From: Bob Braden <[email-masked]>
Date: Tue, 19 Sep 2000 17:39:38 GMT

*> From [email-masked] Tue Sep 19 10:28:30 2000
  *> Date: Tue, 19 Sep 2000 19:24:45 +0200
  *> From: Dusan Sarvan <[email-masked]>
  *> Organization: ASCOM Business Systems
  *> X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.7 sun4u)
  *> X-Accept-Language: en
  *> MIME-Version: 1.0
  *> To: [email-masked]
  *> Subject: RSVP PathError and ResvError messages
  *> Content-Transfer-Encoding: 7bit
  *> X-Filter-Version: 1.2 (ascomax)
  *> Sender: [email-masked]
  *> Precedence: bulk
  *> X-Lines: 78
  *> 
  *> Hi,
  *> 
  *> I am considering to use RSVP as a signaling protocol at the end user
  *> side
  *> (telephone Gateway).
  *> I've studied carefully RFC 2205 spec, but there is a point where I am
  *> not
  *> completely clear from the end user prospective. So if some of you
  *> clarify
  *> the following questions, I will be really appreciated.
  *> 
  *> 1. Let's consider the following scenario:
  *> 
  *> SENDER ---> Router_1 ---> Router_2 ---> Router_N ---> RECEIVER
  *> 
  *> a)  Sender sends PATH message which is processed by the "admission
  *> control" and
  *> "process control" modules on each router downstream along a data path.

No.  RSVP makes reservations from the receiver end.  That is why the
upstream message is called Resv!  Admission control and process control
(which are collectively called traffic control in RSVP) are not invoked
for Path messages.  

  *> If the
  *> PATH message fails some of these controls, PathError message will be
  *> generated

In fact, failure of a Path message should be a very rare event.

  *> and sent back to the SENDER. So SENDER will examine ERROR_SPEC object
  *> and
  *> will know what has caused the fail of reservation process. This is clear
  *> to me, so there
  *> is no question about this.
  *> 

But wrong, in fact.

  *> b)  If RESV message sent from the RECEIVER fails "admission control" or
  *> "process control" on some of the routers, ResvError message will be sent
  *> to the
  *> RECEIVER. In this case the SENDER will never receive the RESV message
  *> and will
  *> never know what has caused the fail, for example no enough bandwidth,
  *> PATH or RESV
  *> messages are lost somewhere between SENDER and RECEIVER due to the
  *> unreliable
  *> delivery mechanism of these messages, or something else.

Why does the sender care what caused it to fail?  Isn't it sufficient
to know that the Resv message never arrived?  In any case, we expect
there is an application-layer protocol that will carry such information
if it is relevant.  In the multicast case, the sender probably does not
want to know about failures of some receiver reservations; it would
not scale.

  *> 
  *> QUESTION:  How to handle this case on the SENDER side? Whether to setup
  *> time out for
  *> the RESV message at the time of sending the PATH message, or to use some
  *> other RSVP
  *> mechanism which I probably have not read correctly in the RFC spec?
  *> Should gateway try to repeat this process once more by sending new
  *> PATH message, or

The nodes along the path will continue trying to send Path and Resv
messages until the end systems stop refreshing or explicitly tear down
the state in place.

  *> to start sending data packets with unreserved bandwidth (?????), or to
  *> refuse the call setup
  *> and to play busy tone?
  *> 
  *> c)   This question relates probably more to the Policy and Network
  *> Management then to
  *> the RSVP problem, but probably someone can answer.
  *> 
  *> SENDER and RECEIVER are connected to the routers which belong to the
  *> different
  *> network domains or ISPs. SENDER is RSVP capable, RECEIVER doesn't
  *> support RSVP.

I answered this same question on another list recently.  Why doesn't
the receiver support RSVP?  I think the question is broken.  I wonder
how you would do Web access if one end does not support TCP or HTTP?

Bob Braden

  *> 
  *> QUESTION: How SENDER knows RECEIVER's RSVP capabilities? It will
  *> retrieve that
  *> information from the Policy /Network Manager
  *> OR
  *> SENDER will initiate the RSVP signaling without having any knowledge
  *> about RECEIVERS
  *> RSVP capabilities, with setting time out for the RESV message? After
  *> this time out (RESV has
  *> not been received - RECEIVER is not RSVP capable, or PATH/RESV are
  *> lost),  SENDER
  *> will start sending traffic with unreserved bandwidth?
  *> 
  *> Thank you very much for your time, and I appreciate your answers in
  *> advance.
  *> 
  *> Dusan Sarvan
  *> SW Designer
  *> Ascom Business Systems AG
  *> Switzerland
  *> 
  *>

---

From: Dusan Sarvan <[email-masked]>
Date: Tue, 19 Sep 2000 20:06:20 +0200

>   *> Ascom Business Systems AG

Hi Bob,

Thank you very much for your quick answer.
Could you clarify please the last point you answered.

SENDER - RSVP capable,
RECEIVER (older version of the telephone GW) - doesn't support RSVP.

This is a real situation in today's networks, that we have a telephone
Gateways which support RSVP and gateways which doesn't support RSVP.

Let's say we have a SENDER telephone GW in New York which supports RSVP
and RECEIVER telephone GW in Geneva which doesn't support RSVP.
How to handle this case?

This clarification is very important to me. Thanks a lot in advance.

Best regards,

Dusan Sarvan

---

From: David Charlap <[email-masked]>
Date: Tue, 19 Sep 2000 16:55:54 -0400

Dusan Sarvan wrote:
> Let's say we have a SENDER telephone GW in New York which supports
> RSVP and RECEIVER telephone GW in Geneva which doesn't support RSVP.
> How to handle this case?

It seems pretty obvious to me.

In this situation, RSVP will not be able to signal QoS along the entire
path.

You could probably set up a router close to the Geneva GW to signal RSVP
to the New York GW.  This will allow QoS to be reserved between the New
York GW and that router. But there will still be no reservations between
that router and the Geneva GW.  It will probably require customizations
to the router's code in order to work.  (Similar customizations are
being made in routers that use RSVP to signal MPLS tunels.)

Doing so, however, will restrict the kind of reservations that may be
made.  Such a router will have to attempt to reserve the specific
resources in the sender's TSpec.  Or it will have to have application-
aware knowledge, in order to intelligently choose some other
reservation.

-- David

---

From: Ping Pan <[email-masked]>
Date: Wed, 20 Sep 2000 09:22:53 -0400

> > RSVP and RECEIVER telephone GW in Geneva which doesn't support RSVP.

David,

> In this situation, RSVP will not be able to signal QoS along the entire

This is correct. What Dusan had pointed out was the fact that the
receiver-orientated reservation in RSVP would not work if the receivers
are not "smart". It's also not clear to me why we have to have two-pass
reservation in *this* case. This problem can be easily resolved if the
reservations are made from the sender's direction in a one-pass
reservation manner. 

Please take a look at the
http://www.cs.columbia.edu/~pingpan/projects/yessir.html for something
that we have been working on for a while. 

> aware knowledge, in order to intelligently choose some other

That right. In many cases, sender's Tspec may be good enough for
receivers. Actually, for routers to merge Sender Tspec's and Receiver
flowspecs (all those LUB and GLB operations) can be quite stressful if
you have to deal with shared reservations for multicast (aka,
many-to-many flowspec merging). That's why please take a look at what we
have proposed.

BTW, IMHO, receiver-orientated two-pass reservation (i.e. RSVP) gives
receivers great deal of flexibility, at the cost of having more
messages, processing cycles and states. Also, we have to understand that
RSVP is a good solution to accommodate different receiver requests in a
heterogeneous multicasting environment.

Thanks!

- Ping Pan