Subject: [MMUSIC] Question Regarding Use of QoS Precondition Without RSVP

From: "Corey Alexander" <[email-masked]>
Date: Fri, 9 Sep 2005 16:02:21 -0500

In August when the Congestion Status Precondition draft
(draft-alexander-congestion-status-preconditions-00.txt) was presented,
it was suggested that the 'qos' precondition as defined in RFC3312, and
updated in RFC4032, could be reused for the Real-time Explicit
Congestion Notification scheme, instead of defining a new precondition
as had been proposed.

Having read through RFC3312 and RFC4032 multiple times, we would like
comments on this as to whether reusing the 'qos' precondition is really
feasible.

What we have found is that, while neither RFC3312 nor RFC4032 come right
out and state explicitly that the 'qos' precondition must utilize RSVP,
it does appear to be an implicit presumption that RSVP be used.  Various
sections within RFC3312, described at the end of this message below,
illustrate this.

Having pulled references from RFC3312 that describe resource reservation
both generically as well as in terms of RSVP, it seems that while
RFC3312 does not explicitly dictate the tying of the 'qos' precondition
to RSVP, it does go a long way to imply it.  And the few places where it
leaves the 'qos' precondition open to use with other resource
reservation mechanisms, or otherwise speaks generically to it, leave it
very unclear how the 'qos' precondition is tied to any particular
mechanism at all, RSVP or otherwise.

There are also other interpretations of RFC3312 that seem to have
inferred that the 'qos' precondition means RSVP must be used.  One
example is draft-ietf-tsvwg-mlpp-that-works-02.txt, where in "Appendix
A.  2-Call Preemption Example using RSVP", when referring to the two
'qos' a-lines in the SDP sent with the initial INVITE, it is stated that
"The next two a-lines are the only identifiers that RSVP is to be used
for this call."

The suggestion made in August was that the 'qos' precondition can be
reused for RTECN, instead of defining a new precondition.  With what has
been identified here, there is concern that an existing implementation
of the 'qos' precondition which presupposes the use of RSVP will not
interop properly with an implementation which presupposes (or explicitly
indicates) an alternate method of resource reservation or some other,
non-reservation mechanism.  In our case, if we reuse the 'qos'
precondition for RTECN, there is a high likelihood of interoperability
issues if an originating device uses 'qos' with RTECN and the
terminating device only knows 'qos' with RSVP.  The RSVP device would
recognize the 'qos' precondition, but would not know to treat it other
than with RSVP, thereby starting resource reservation via RSVP, while
the originating device is waiting/listening for ECN probes.

So the question is this: Can the 'qos' precondition really be used
without the possibility of interoperability issues?  If not, what other
option is there other than to define a new precondition?

Thank you,
Corey Alexander
[email-masked]

RFC3312 references to resource reservation and/or RSVP:

>From the "Abstract" section in RFC3312:
   We do not define new quality of service reservation mechanisms; these
   preconditions simply require a participant to use existing resource
   reservation mechanisms before beginning the session.
This does refer to there being multiple resource reservation mechanisms,
versus a single one, which will be noted later.

The "2 Introduction" section in RFC3312 uses the following phrases:
"reserve network resources", "reservation of network resources",
"resources cannot be reserved", "without performing resource
reservation", and "confirmation of a resource reservation".

The "3 Overview" section in RFC3312 talks in terms "resources reserved
in [] directions", and discusses an example in Figure 1 which is
described in terms of resource reservation.

The "4 SDP parameters" defines the media level SDP attributes for
preconditions, specifically the "Status type" attribute, in terms of
"reservation of resources", "access network reservations", "resource
reservation mechanisms", and "resource reservations," with Figure 1
showing "RESERVATION" taking place during preconditions.

Next, the "5.1 Generating an offer" section indicates that the "Current"
field of the "local status table" contains a "yes"/"no" indication of
whether "successful reservation of that resource" has been made, or
"resources have not yet been reserved yet".  Also, the "strength-tag"
semantics described here indicate "no resource reservation is needed",
"agents SHOULD try to provide resource reservation", and "agents MUST
provide resource reservation".

Section "5.1.1 SDP encoding" in RFC3312 describes an answerer requesting
"quality of service reservation" by upgrading the "strength-tag" value
"without the need of another offer/answer exchange.

Section "5.2 Generating an answer" in RFC3312 again describes the
"Current Status" ["Current"] field in terms of "confirmation of a
resource reservation" having been received.  In later text, there is
again another reference to there being multiple resource reservation
mechanisms - "If the resource reservation mechanism used..." - and
continues in terms of "start resource reservation" and "status of the
resource reservation."

Section "6 Suspending and Resuming Session Establishment" in RFC3312
mentions on example of a PSTN gateway reserving resources.

Section "7 Status Confirmation" in RFC3312 describes the
"confirm-status" attribute representing a "threshold for the resource
reservation", a new offer sent to the peer containing "the current
status of resource reservation," and a user agent sending an offer "as
soon as it reserves resources."

The next section mentioning reservation in RFC3312 is "13.1 End-to-end
Status Type".  This section provides an example of the 'qos'
precondition using the "end-to-end" status type, and explicitly presumes
that both agents A and B use RSVP.  A second example is provided that
also presumes that both agents use RSVP.

Section "13.2 Segmented Status Type" of RFC3312 provides another
example, described in terms of "reserves resources", etc., but does not
explicitly describe the use of RSVP.

Section "13.3 Offer in a SIP response" of RFC3312 provides another
example, this time again explicitly describing the use of RSVP for
resource reservations.

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