Subject: Re: FW: [SIP] Feedback on manyfolks

From: William Marshall <[email-masked]>
Date: Thu, 26 Oct 2000 13:01:58 -0400 (EDT)

Gonzalo writes:
> In some situations the UAC wants the UAS to "wait" until there is a
> COMET (UAC->UAS). This decision MUST be done by the UAC because the UAS
> does not have a clue about this need.
> 
> You can find an example in 
> http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt
> 
> We have A, a transcoder and B. The media path will traverse the
> transcoder.
> 
> The presence of a transcoder is transparent to B. The SDP of the INVITE
> from A to B contains the IP address of the transcoder. Thus, even when
> the QoS is granted in the transcoder-B leg, there is a need for QoS in
> the other leg (transcoder-A). B is completely unaware of this, so it is
> A (the UAC) the one that MUST require a COMET from UAC to UAS.
> This way, it can perform resource reservation between A and the
> transcoder and then send the COMET to B (that will resume session
> establishment).
> 
> Note that in this example I use 2 COMETs between A and B, but actually
> COMET from B to A is not needed for anything.
> 
> However, in the other leg (transcoder-A), 2 COMETs are needed.
> 
> This illustrates that the UAC always has the information about how many
> COMETs are needed.
> 

I've gone through 3pcc-qos-00 (and also manyfolks-confirm-00, which
repeats the first example from 3pcc-qos-00), and believe we 
already have all the cases covered.

In the simple third-party-call-control case, the controller uses
the "confirm" in the SDP sent with the INVITE, which causes a two-way
COMET.

The second example in 3pcc-qos-00 consists of a simple call from A
to the transcoder, T, followed by A acting as a third-party-controller
to establish a call from T to B.  The second half of this example is
covered by the previous.

For the simple call from A to T, A inserts the SDP line a=qos:mandatory 
sendrecv" which T is willing to accept.  But T can't do the send&recv QoS
itself - it needs help from A for the A->T direction.  
(Note that T doesn't know whether A will be using RSVP, so it can't
depend on using a RESV-CONF to do this trick).  Therefore it needs
to ask for the confirmation; without it T would be proceeding with the
session establishment without fulfilling the preconditions.  So it
asks for the confirmation in the 183 response.

Consider the case where T implements some other (i.e. non-RSVP) resource
reservation protocol.  If it can somehow get send&recv QoS from A to T
by itself, then it can locally determine that it has met the preconditions.
In this case there is no need for the COMET, and giving A the capability 
to demand one actually increases the call setup delay.

> OK, now, let me re-write my suggestion (it appears already in my
> previous mail):
> My suggestion is:
>      UAC sends               result
>      comet sendrecv          2 COMETs, UAS->UAC, then UAC->UAS
>      comet send              1 COMET, UAC->UAS
>      <nothing>               0 COMETs
> 
> This mechanism includes all the comments received in this thread so far:
> 1) It is simple, because there is no negotiation of how many COMETs have
> to be sent. The UAC makes the decision and the UAS obeys.
> 
> Question: Do you have any situation where the UAS would like to change
> the decision made by the UAC regarding the number of COMETs sent? I
> cannot think of any useful scenario.

If we consider that there are reservation protocols other than RSVP,
and in particular ones that can make bi-directional reservations,
then the UAS would be in a better position to decide the proper number
of COMETs than the UAC.

> 
> 2) It saves one RTT in the most common situation (just one COMET
> UAC->UAS).
> 
> 3) The syntax is really "human readable". Direction tags are very easy
> to interpret. Even easier when they are already used in the a=QoS line.
> 
> 
> Do you have any objection against this approach?
> 
> Practically this is the same mechanism described by Jonathan (where the
> UAC also makes the decision). I have just added the posibility of just
> one COMET (for saving bandwidth basically).
> 

My only real objection to this approach is that it duplicates a facility
already provided in the manyfolks procedures, and I see no reason to
require two ways to force the same behavior.

A secondary objection (relatively minor) is that I always get confused
when we use the terms "send" and "recv" between two parties that both "send" 
and "recv"; a "send" interpreted by one party is the "recv" of the other.
Note that table 1 of section 4.2 of the current manyfolks draft has
a glaring error due to the confusion, and this mistake has appeared in three
versions before being caught.

Bill Marshall
[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 28 Oct 2000 00:07:21 +0300

Hi Bill,

William Marshall wrote:

> depend on using a RESV-CONF to do this trick).

So, T does not know whether A uses RSVP or not...
Is there a negotiation of the QoS reservation scheme used?
That is, my terminal sends an INVITE with SDP preconditions (sendrecv),
and I get the 183 with the same preconditions (sendrecv). What should my
terminal do?

Should it use RSVP to reserve resources in the recv direction and expect
the other end to do the same in the other direction?
Should it reserve resources for send&recv over its radio access and
expect the other end to perform also resorce reservation on its access
(maybe an ethernet)?
You mention also bi-directional resource reservation schemes. Should my
terminal use its bi-directional resource reservation mechanism and
perform the sendrecv reservation?

Who decides which resource reservation mechanism is to be used?
Do we need negotiation of the reservation mechanism?

  Therefore it needs
> require two ways to force the same behavior.

I am proposing to go for just one mechanism. That's why we are
discussing which one is the best. Once we have consensus, we implement
just one.

> and "recv"; a "send" interpreted by one party is the "recv" of the other.

If you are serious about this objection, let's change also the direction
tag of the QoS line, because it uses the same mechanism. I believe that
if sendrecv kind of tags are already used in the QoS line, they can be
used as a direcion tag for the confirm also.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland