Re: [Sip] Still issues with preconditions

[William Marshall <wtm@research.att.com>]

Alan O'Neill raised a question about the manyfolks draft
after the end of the last call discussion.  The question
basically is about choice of resources when both UAC and UAS
perform bi-directional reservation.

While I addressed this in my presentation at IETF52, a response
to the list was requested.

This situation occurs in the following sequence.  The UAC sends an 
INVITE with a preconcition line in the SDP "a=qos:sendrecv mandatory"  
The UAS responds with "a=qos: sendrecv mandatory confirm"  Both 
the UAC and UAS attempt to reserve resources, both of which perform 
bi-directional reservations, both of which succeed.  

The draft is perfectly clear about the need of both the UAS and UAC
to attempt to make the reservations, but not clear on whose resources 
should be used.

The proposal from Flarion adds significant complexity in initial 
SDP contents indicating the resource reservation capabilities of 
the UA, and the existance of any pre-existing resources, so that 
this double reservation can be avoided.

This situation can be resolved very simply by the entity receiving
the COMET (typically the UAS).  Certain resources are identified in 
the COMET, and the UAS merges those with its locally-reserved resources.
Any overlap is detected by the UAS, and redundant resources should
be released by the UAS.  I'll add a sentence to that affect.

There is certainly a problem when resources exist for only one call,
and both the UAC and UAS attempt (and fail) to reserve them.  This is 
commonly called glare, and is a variation of the classical dining 
philosopher problem.  The solution is complex, is not handled in
the current draft, and (I propose) should stay that way.



The other point raised by Alan is more up for discussion.

Resource reservation can logically be divided into segments between
the UAC and UAS, and there are different ways to partition the problem.

Consider the following diagram:
         /-1-<<-2-<<-3-\
        A               B
         \-4->>-5->>-6-/

While systems can certainly obtain QoS prior to sending the INVITE, that
leads to a vertical partitioning (the so-called segmented qos model).
UA #A can ensure QoS in segments 1&4, UA #B ensures 3&6, and both assume
diffserv for 2&5.  This scenario can certainly be optimized.

The manyfolks draft assumes a horizontal partitioning, and only includes
syntactic mechanism to describe the 1&2&3 combination (A:recvonly) and the 
4&5&6 (A:sendonly).

Should additional terms be defined in manyfolks draft, such as "access"
and "backbone" to enable this vertical split?  Second, are these the
right terms?  Comments?


Including success of preconditions without knowing the destination seems
to require a crystal ball.  Good topic for a separate I-D.

And, just for the record,

Alan O'Neill wrote:
> ... I have tried to
> raise / resolve issues with the authors of the draft but have so far not had
> any response. 

First I heard of this issue was email on Monday 10 December, and actually read 
the message from Rakesh first, also 10 December, which stated the status of manyfolks 
draft was "Looking at some late comments"

Bill Marshall
wtm@research.att.com

-----original message-----
From: "Alan O'Neill" <A.ONeill@flarion.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Mon, 10 Dec 2001 03:06:27 -0500
Subject: [Sip] Still issues with preconditions

Version 3 of the manyfolks-resources draft has appeared but there still
appear to me to be a number of issues with this document. I have tried to
raise / resolve issues with the authors of the draft but have so far not had
any response. 

In summary;

i)	The strength-tag appears overloaded in attempting to carry both
requirement (Mandatory/Optional) and progress (Success/Failure) information.
This prevents a node with precondition resources already in place (existing
resources in call waiting / dimensioned diff-serv QoS) from including the
Success progress in an Invite which in the general case would lead to very
fast and efficient call set-up. In the case of incapability, the caller
could signal the inability to meet a precondition direction itself with a
Failure which would enable the callee to immediately and quickly detect
impossible preconditions when merged with its own incapabilities. The
limitation of the overloaded strength-tag could be avoided by using an
additional result-tag in each precondition to signal progress separately
from the requirement in the strength-tag.

ii)	The draft is clear on the negotiation phases of the precondition
signalling and how direction-tags in requests, responses and COMETs are
related. However, it is not at all clear how end nodes actually work out how
to respond to offered preconditions and how they work out which resources
each end should attempt to meet, especially regarding whether preconditions
must/may/must not be attempted in parallel or in series at the caller and
callee. This ambiguity is clearly a barrier to the production of multiple
interworking implementations and leads to inefficient call set-up and
cleardown, as well as the danger of each end trying to book the same
resources.


I'll use a brief and specific example in an attempt to get some discussion
on the second issue which is maybe less obvious than the first...

In the first example in the draft, the caller requests a sendrecv resource
precondition and includes a confirmation request. The callee cannot tell if
the caller is able or wishes to meet either send or recv direction in the
sendrecv precondition, only that it wishes to be informed of progress. The
callee responds with sendrecv confirm but the caller cannot glean any
information from the inclusion of the confirm by the callee. This is because
the callee confirmation request is mandated in the draft in response to the
caller confirmation request. The only information exchanged (that I can
glean from the draft) so far is that the callee, in accepting the sendrecv
precondition, is informing the caller that it can contribute in some way to
meeting the sendrecv precondition.

The caller now sends a PRACK and repeats the precondition it sent in the
Invite. At this point, the example says that both the caller and callee can
in parallel start booking resources to meet the sendrecv precondition but
this opens up the possibility of problems because neither end has actually
agreed with the other end on which of the precondition directions it is
going to attempt (ie lead roles in meeting preconditions). The model only
works if both ends have the same unidirectional reservation capability (send
only or recv only) such that non-overlapping resources are booked. If both
ends can book both directions (sendrecv) then full duplication is possible
(double the resources). If both ends have opposite capabilities (caller
send/recv and callee recv/send) then one direction will get double the
resources and the other will have no resources booked. The double / missing
resources will always be detected by the caller because the callee COMET
will include success/failure separately for each direction so that the
caller can recover, but clearly the caller can only then change its
reservation status because no mechanism exists to get the callee to do so.
The existance of duplicate reservations is clearly unfortunate and could be
avoided if the preconditions negotiation was explicit about agreeing which
resources each end should attempt to reserve.

I hope one of the authors will be kind enough to help me with this....

Regards,  Alan O'Neill

----------------------------------------------------------------
Notice Regarding Intellectual Property Rights

Flarion's submissions will conform with RFC 2026.  Flarion may seek patent
protection on some or all of the technical information submitted by its
employees in connection with the IETF's standards process.  If part(s) of a
submission by Flarion is (are) included in a standard and Flarion owns
patent(s) and/or pending patent application(s) that are essential to
implementation of such included part(s) in said standard, Flarion is
prepared to grant a license on fair, reasonable, reciprocal (license back)
and non-discriminatory terms on such included part(s).




_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip