Subject: Re: Cross-domain QoS setup

From: William Marshall <[email-masked]>
Date: Wed, 23 Feb 2000 00:45:06 -0500 (EST)

Jonathan Rosenberg wrote:
> The difficulty arises only with the segmented DQoS model in DCS, which
> does not provide a way to confirm resource reservation (I think),
> whereas RSVP does.
...          .....      ... The mechanism exists already now
> in RSVP, but not in DQoS (DCS folks, please correct me if I am
> mistaken).  

RSVP only provides this if (1) both endpoints support RSVP, and (2)
the backbone transports RSVP.  Neither is a valid assumption in
DQoS or DCS.

Further, please remember the address privacy requirements.  Whatever
the confirmation message looks like, the anonymizer must be able
to parse and rewrite it (just like it does for SIP messages) to update all
the addresses.  A single mechanism is much preferred.

Bill Marshall
[email-masked]

----- original message -----
> 
> 
> "Adam B. Roach" wrote:
> > The current draft makes an assumption that end-to-end network 
> > resource reservation is controlled by a single entity. For calls
> > being placed across adminstrative domains, however, this will
> > not be the case. Under such circumstances, the reservation of
> > resources needs a greater degree of coordination than is 
> > currently provided in the draft.
> 
> Not really. Resource reservation is under the "control" of all the
> network elements along the path that perform some kind of admission
> control and resource allocation. These elements will often belong to
> different administrative domains. The draft makes no assumptions about
> the number of providers along the reservation path, or anything like
> that. It only ties resource reservation and signaling together at the
> endpoints, dicatating a particular temporal sequence.
> 
> > 
> > In particular, the calling user agent needs the ability to
> > communicate to the called user agent that it has reserved
> > the necessary resources on its end, and that alerting may
> > begin as soon as the called user agent has done the same.
> 
> This is something different from what you are discussing above. It is,
> in fact, covered in the draft. If A calls B, the RSVP RESV message from
> A to B confirms resources are reserved from A to B, and the RESVCONF
> from A to B confirms resource reservation from B to A. This allows B to
> know whether resources are reserved in both directions. A mirror case
> exists for A. 
> 
> The difficulty arises only with the segmented DQoS model in DCS, which
> does not provide a way to confirm resource reservation (I think),
> whereas RSVP does.
> 
> So, the question is this. We know we need a way for both parties to know
> when resources are reserved in both directions. Is this a function that
> belongs somewhere in SIP (through INFO, as you propose, or some other
> means), or in a reservation protocol. The mechanism exists already now
> in RSVP, but not in DQoS (DCS folks, please correct me if I am
> mistaken). So, do we add it to SIP, in which case its not needed for
> RSVP, or should it be added to DQoS, in which case the SIP operation is
> independent of the underlying reservation mechanism?
> 
> I have argued that confirmation of resource reservation is rightly a job
> for a resource reservation protocol. One of the things I like about SIP
> is its separation from session level control and network layer issues,
> such as resource reservation.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Feb 2000 03:06:26 -0500

> the addresses.  A single mechanism is much preferred.

Well, an anonymizer can't have just a single protocol mechanism. By its
very definition, the anonymizer must handle both SIP and RTP at least,
which is already two protocols. Since its handling media streams, it
must also initiate and terminate QoS reservations if you want voice
quality through the anonymizer. So, its already doing resource
reservation. If the resource reservation protocol is providing
confirmations, its not any extra protocol work as compared to putting
these confirmations in the signaling protocol.

-Jonathan R.