Subject: RE: [Sip] Still issues with preconditions

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 8 Jan 2002 07:48:37 -0500

Thanks for the response Bill

Comments in-line

-----Original Message-----
From: William Marshall [mailto:[email-masked]]
Sent: 27 December 2001 17:16
To: [email-masked]
Subject: Re: [Sip] Still issues with preconditions

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.

AWO> My questions were specifically about the problems/limitations caused by
the overloading of the strength-tag, the combined sendrecv direction-tag and
the ambiguity in the processing caused by the protocol not actually
resolving lead roles (ie who should attempt to book resources). The example
of both ends being capable of bi-directional reservations is one case in
which problems are exposed but is by no means the worst case as I'll explain
later.

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

AWO> This is appreciated Bill as I was not able to get to the IETF due to my
newborn son.

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.

AWO> the example is clear on that issue but the draft also says that
resources can be booked either in series or in parallel in specific
circumstances - hence ambiguity about when parallel and serial can or 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.

AWO> It is one new <result> tag which is hardly 'significant complexity'
Bill and that new tag solves a number of issues, not just the specific case
presently being discussed of both ends with bi-directional capability. The
ambiguity in the sendrecv direction-tag and the overloaded strength tag
leads to 'impossible' preconditions not being detected until after a
significant amount of signalling (COMET). I think the worse case would be a
sendrecv precondition when both ends have opposite unidirectional
capabilities..discussed later.

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.

AWO> Well this eventually solves the double booking but is clearly very
unfortunate and a somewhat cumbersome process I think you would agree.

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.

AWO> Flarion develops technology for cellular basestations where each cell
typically has a small number of voice call slots so this overbooking is very
unwelcome both to us and I would suspect also to 3G solutions. The problem
is I am sure you agree greatly reduced with the information processing I
have previously outlined. What is clearly needed is a means to signal an
endpoints capabilities. This is only possible by separating the
direction-tag so that send and receive direction capabilities can be
uniquely signalled (this split is needed and used in the COMET for the same
reasons but is often too late to avoid wasted signalling for impossible
preconditions). Then the result-tag (removing the overloading of the
strength-tag) associated with a direction-tag can now inform an endpoint of
the other ends capabilities immediately in the offer. The example under
discussion of endpoints with bi-directional capabilities is not the only nor
main reason to do this. Take the case where the precondition can not
possiblly be met. Now the earlier either end can determine this then the
better because any signalling is simply wasted (a particularly bad situation
for bandwidth constrained access such as cellular). Clearly signalling
offerer capabilities enables the receiver of the SDP to immediately detect
impossible preconditions and to rapidly refuse the call, minimising wasted
signalling and the duration of held and hence wasted resources. If the
receiver doesn't detect the impossible precondition then its answer will
enable the sender to so detect. Only QoS signalling failures due to resource
constraints or equipment problems can then produce preconditions that
ultimately fail after a significant amount of signalling exchanges occur...

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).

AWO> Not necessarily so. Existing resources can also exist in the horizontal
model. The resources can be pre-signalled with RSVP for a hot-line
application during emergencies for example and then the SDP could be sent
informing the other end that the resources already exist leading to rapid
call set-up. Another example is call-waiting via a media gateway shared by
the existing and new call such that the resources again exist. Making any
assumption about how QOS is actually done or where the mechanism will be
useful to operators is a dangerous game. The SDP preconditions mechanism
should simply provide a means for user to exchange best guesses on resource
availability given their QoS protocols, SLAs and other configuration.

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.

AWO> This is a common case in IP backbone networks where the operators have
dimensioned the core and the access is constrained. There are other models
in the enterprise where the resource dumbell is reversed such that the
access is plentiful and the core constrained. Essentially though, if the
user via the operator SLA knows that it only needs to deal with the access
then a 'general' SDP preconditions signalling capability should be able to
deal with it in my book. Why overload tags when we can be clear and clean,
and still be open to future enhancements to the interactions between QoS
protocols and SDP preconditions. If you would be happy to modify the tag
structures as suggested then I would be more than happy to take the wider
scope of the preconditions signalling into a new draft and progress that as
a future enhancement to SDP preconditions. This cannot be done though unless
the tags are redesigned or a parallel set of tags and processes developed
which I think none of us would wish...I hope you can see that

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).

AWO> Well that assumption should be stated clearly because it claimed to be
all embracing when it clearly is not. Thats fine but if it is not all
embracing then the mechanism should be designed to enable other models to be
supported from future drafts. However, even with your horizontal model you
have a number of problems to adddress. The horizontal model assumes
admission control and resource booking on all segments on the paths 123 and
456. Lets take RSVP..now what are you going to do if the RSVP reports a
non-RSVP cloud ? You could go either way but ultimately the only reasonable
thing to do depends on the assurance given to the user by the operator for
its QoS mechanisms. Another example would be an operator using aggregate
RSVP over a diff-serv backbone with statistical overbooking. Is this good
enough to enable a user to meet the horizontal assumption or not, clearly it
depends on the degree of overbooking which is directly related to the level
of assurance given by the oeprator for there QoS mechanisms and should be
reflected in the associated settings for its users hosts when processing SDP
preconditions. The vertical and horizontal models are in summary far to
simple to be real and meaningful and certainly do not represent either the
present or future limits of what will be done. Therefore, we must
disassociate these models from the SDP preconditions signalling and trust
the users application to do the right thing given knowledge from its
operator via config or policy....

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?

AWO> In all cases, the user software should be aware of how it can respond
to offered preconditions given its QoS capabilities and its SLA with its
operator. This response should be outside the preconditions draft and should
instead be in a document discussing the mapping between preconditions and
network QoS mechanisms and topologies. The draft should continue to include
the simplified horizontal example whilst these mappings are agreed in my
book...

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

AWO> Exactly, but you are equally assuming a crystal ball becasue you are
also assuming that the horizontal model has undertaken node by node
admission control and resource booking which I doubt many networks will ever
support. I hope you can see the problem with the assumptions about QoS
protocols and operator, inter-operator models....and the need to separate
preconditions signalling from these assumptions in this draft...

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"

AWO> Well then Bill I apologise if my e-mails were not received by you. I
certainly made a couple of attempts to reach you privately and also had no
feedback from my e-mails to the list till now. I greatly appreciate your
response and hope we can reach concensus on this quickly so that the draft
can progress..

AWO> Please consider my suggestion for redesigning the tags to be more
general and then limiting the scope of your draft to the simple horizontal
case with no pre-booked resources or capabilities exchange. Your draft can
then progress rapidly whilst we write up the extensions in a new draft to
support capabilites exchange and lead role negotiation, and to also address
the vertical model. We can then take requirements from operators/vendors on
the appropriate behaviour for a node given its QoS capability and SLA, and
then turn this into a future mapping draft so that all internet nodes can
process preconditions consistently within an agreed broad framework. I hope
that is a reasonable and useful suggestion to you and your co-authors.

Regards, Alan O'Neill
Flarion Technologies (www.flarion.com)

-----original message-----
From: "Alan O'Neill" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 8 Jan 2002 07:48:43 -0500

Hello Brian, 

Please see my previous note to Bill which I think covers my views on your
points..

I'd specifically appreciate your perspectives on my points on resource
booking and wasted signalling in the context of 3G access if that is your
poison :-)

Nothing in-line..

Thanks,  Alan.

-----Original Message-----
From: Brian Williams [mailto:[email-masked]]
Sent: 29 December 2001 12:36
To: William Marshall
Cc: [email-masked]
Subject: Re: [Sip] Still issues with preconditions

Hi All.
On Fri, 2001-12-28 at 04:16, William Marshall wrote:
:
<snip>

> 4&5&6 (A:sendonly).
The draft specifies that resource reservation takes place using whatever
protocols the participants must use. Therefore, the precondition
mechanism must not be dependent on any specific "partitioning" of the
QoS controls. 

I believe the solution is not actually dependent on any particular
partitioning, but the explanatory text certainly focuses on the
horizontal partitioning indicated.

> and "backbone" to enable this vertical split?  Second, are these the
The preconditions mechanism provides a general means to co-ordinate the
call session with other aspects. Although it does specify the
preconditions to be met, the manyfolks draft does not consider any
details of the actual mechanisms used to meet the preconditions. From
this perspective, manyfolks should not need to identify many different
QoS scenarios which require different behaviours. Rather, the draft
should simply be clear that each participant believes that they have met
the QoS pre-conditions they have indicated. This may simply require some
clarification of the wording to ensure that each participant does
evaluate its own view of the QoS conditions when merging with the remote
participants conditions.
/brian 
had
read 
> the message from Rakesh first, also 10 December, which stated the status
of manyfolks 
> Bill Marshall
> [email-masked]
had

---

From: "Shieh, Hugh" <[email-masked]>
Date: Tue, 8 Jan 2002 11:03:35 -0800

Comments inline.

-----Original Message-----
From: Alan O'Neill [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2002 4:49 AM
To: William Marshall; [email-masked]
Subject: RE: [Sip] Still issues with preconditions

Comments in-line

-----Original Message-----
From: William Marshall [mailto:[email-masked]]
Sent: 27 December 2001 17:16
To: [email-masked]
Subject: Re: [Sip] Still issues with preconditions

Snipped...

Hugh> The actual QoS mechanisms are outside the scope of this draft,
however, I believe the definition of preconditions is within the scope. As
Bill pointed out that the existing definition in the draft (sendonly,
recvonly, sendrecv) assumes the horizontal end-to-end model. I see the value
of defining the precondition for the vertical model in the draft (to avoid
future interoperability problem). In some network, there are "access" and
"backbone", the resource in the "backbone" can be statistically provisioned
with possibility of semi-dynamic reconfiguration, and the "backbone"
resource may not be reserved at per call basis. However, the resource in the
"access" part of the network need be reserved at per call basis (e.g., 3G
wireless). In this case, UA can only know and need only know if the "access"
part of precondition can be satisfied. I would support to define an "access"
precondition in the draft.

-Hugh

Snipped...

---

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 9 Jan 2002 00:52:38 -0500

Hi Hugh, thanks for your input
 
So I can definitely see how both the apparently 'simple' pure horizontal and
the vertical cases can be covered in the existing doc, I am concerned though
that you will open up a rat-hole as different network architectures and QoS
models get thrown into the pot. I think we still need a separate doc to
cover UA behaviour given specific QoS capabilities and assumptions. As I
tried to point out before, even the end to end RSVP case has the non-RSVP
cloud to deal with. Does this cause preconditions to fail or pass - this is
really not clear and depends on the operators agreements? I think the access
only vertical model is the one concrete case and is also is very important
(as illustrated by your 3G example) and so can be easily included in the
document I feel.
 
Overall though (and maybe best left till later), it would be better if the
SDP preconditions documentation defined some assurance oriented terminology
that was QoS protocol / topology independent that guided how a UA should
interact with SDP preconditions. A separate doc then needs to define how
different QoS capabilities and topologies map to these assurance levels. The
operator then needs to advise its UAs of their level of assurance for
different destinations (intra-domain, inter-domain national, inter-domain
international etc. Note this has to be done anyway even in the 'simple' case
of the RSVP based horizontal model because the UA needs to know how to react
to non-RSVP clouds to different destinations which can be operator /
topology / destination specific..

-----Original Message-----
From: Shieh, Hugh [mailto:[email-masked]]
Sent: 08 January 2002 19:04
To: 'Alan O'Neill'; 'William Marshall'; [email-masked]'
Subject: RE: [Sip] Still issues with preconditions

Comments inline. 

-----Original Message----- 
From: Alan O'Neill [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, January 08, 2002 4:49 AM 
To: William Marshall; [email-masked] 
Subject: RE: [Sip] Still issues with preconditions 

Comments in-line 

-----Original Message----- 
From: William Marshall [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 27 December 2001 17:16 
To: [email-masked] 
Subject: Re: [Sip] Still issues with preconditions 

Snipped... 

-Hugh 

Snipped...