Subject: RE: [Sip] Manyfolks version 04

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Tue, 26 Feb 2002 17:06:16 -0000

Hi Gonzalo,

Thanks for your answer to my offer,

See below in line my new offer:-)

Xin Chen

Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 26 February 2002 15:53
To: Chen, Xin (Xin)
Cc: sip; Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott;
[email-masked]; Jonathan Rosemberg
Subject: Re: [Sip] Manyfolks version 04

Hello,

"Chen, Xin (Xin)" wrote:
> 
> The question I have in mind is why we need "local" and "remote" here.
> 
> "a=des:qos mandatory local sendrecv" generated by the offerer has no
meaning
> to the answerer, because this is something that the answerer can not help,
> because this is your(offerer's) network not mine(answerer's)!

The concept of e2e qos has been present in this draft since the
beginning. We have now introduced the new segmented type, which includes
the tags you are referring to (local and remote).

If I (the offerer) reserve network resources for the media stream in my
local interface and then send you the INVITE, you are right that this
information may be considered useless for the answerer. However, I might
want to, first send the INVITE and see if the answerer is willing to
establish a session using qos. If the answerer responds to my INVITE
accepting my mandatory preconditions, I can begin reserving resources in
my local interface. In this case, I need a way to communicate the
answerer that I am done with my local interface. That's why we need both
tags.

[XC] Bacially, I think we properly don't need such a parameter--"e2e, local
or remote" at all. Becuase the machaism in manyfolks is based on the purely
trustship between offerer and answerer. If I tell you that I have done the
e2e Qos reservation which I don't, you don't know I am saying the truth or
not and you can't verify that. Therefore, the "e2e, local or remote" will
only have local meaning based on local UE's interception. There is no way to
stop me to send you a confirmation for the e2e QoS reservation even if I am
not able to do that. And this is good, because I have some other local means
to satify the QoS condition and I don't want the call to fail becuase I
don't support an e2e QoS reservation protocol. The only important
information carried in the offer is the "mandary", which tells the other end
to try your best based on your own capability regardless you can do e2e or
not. And the important information in the confirmation is that I have done
my best to satisfy the QoS requirement and please trust me!

Therefore, in the case you mentioned, you can always send a test offer with
"qos sendrecv mandary" to the callee but without the "e2e", "local" or
"remote" parameter, let the callee to decide what to do to satify the
condition. This will give great flexibilty to the callee to try his best and
it is much less chance a call will be failed.
 
> And "a=des:qos mandatory remote sendrecv" generated by the offerer has the
> same meaning as "a=des:qos mandatory e2e sendrecv" from the anserer's
point
> of view.

No, they don't. If I am a 3GPP terminal, establishing the appropriate
PDP context will meet the first precondition, but not the second.
[XC] Then the call may fail, we don't want that happen! We wish the call
always successful! This is exactly my worry about the e2e parameter. In
3GPP, the terminal will not do RSVP and it uses PDP which is a local QoS
machanism. We have Differv in the middle to provide the end to end QoS. We
don't want a call to fail if an incoming  offer requiring "e2e" to a 3GPP
terminal or a 3GPP terminal initiates an offer with "local" parameter not
"e2e".

The e2e type is intended for e2e reservation protocols (this is stated
in the draft, by the way).
> 
> I think only "e2e" is needed. Because as a user, I don't care what local
> access network another end is using, actually I even don't know what
> protocol the other end is using for QoS, what I want is end to end QoS for
> my the video or audio streams.

OK, so you will always use e2e qos. But other folks find it useful to
have the segmented type... although this does not mean that you have to
use it.
[XC] No, my point of view is not to use any of them:e2e, local or remote.
Thanks

Thanks for your comments,

Gonzalo

>Therefore, it is up to the user agent to
> intercept and decide whether e2e condition is met or not.
> 
> For example, if the answerer receives an offer requiring e2e QoS sendrecv,
> but the answerer only supports local network QoS protocol and uses Differv
> in the core network to provide end to end QoS, therefore this call should
> not fail just because the answerer doesn't support RSVP. So answerer just
> needs to finish the local network QoS reservation and ACKs the offerer
that
> e2e is met. In a word, for the answerer's point of view, "e2e"="remote".
> 
> If an offerer doesn't support e2e QoS protocol, it can still put "e2e" in
> its offer, because from the offerer's point of view, "e2e"="local".
> 
> Thanks
> 
> Xin Chen
> 
> Lucent Technologies
> Tel: +44 1793 883137
> Mobile: +44 7799 034668
> 
> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 26 February 2002 3:03
> To: sip
> Cc: Allison Mankin; Dean Willis; Biran Rosen; Joerg Ott;
> [email-masked]; Jonathan Rosemberg
> Subject: [Sip] Manyfolks version 04
> 
> Hello,
> 
> I have just submitted a new version of the manyfolks draft. Until it
> appears in the archives, you can fetch it from:
>
http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.pdf
http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-manyfolks-resource-04.txt
> 
> About the authorship of this draft, the ADs and the WG chairs decided
> that all the coauthors of previous versions but Bill had to be moved to
> a Contributors Section.
> 
> The deadline for this draft is very close, so I would appreciate that
> folks read the draft and send comments as soon as possible.
> 
> I have removed security preconditions (per mailing list discussion), but
> added a token that can be used to define new precondition types (the
> only type currently defined is "qos").
> 
> The draft uses two attributes: desired-status and current-status. When
> the current status reaches (or goes beyond) the desired status the
> preconditions are met. Instead of defining an absolute ordering for
> these two attributes, I have defined status tables. They are
> abstractions of the preconditions carried in the SDP. These tables help
> explain how status synchronization between both user agents is performed
> and when exactly all the preconditions are met.
> 
> Feedback is appreciated,
> 
> Best regards,
> 
> Gonzalo
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              [email-masked]
> 
> _______________________________________________
> Sip mailing list  https://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

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
Sip mailing list  https://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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Feb 2002 12:19:34 +0200

Hello,

> [XC] Then the call may fail, we don't want that happen! 

If the preconditions cannot be met, that's exactly what we want: the
call does not have to be established.

Reading your second mail, what you want is the segmented type: that is,
you are telling the other end to do whatever he can on his side, and you
will do whatever you can on yours... as you said, in the middle you
might have DiffServ, for instance. 

But if you use the e2e type, you want to make sure that there are
resources end to end. Even if you know that you are in a Gigabit
ethernet and that your local router uses DiffServ, you still don't know
whether or not you have e2e QoS... that's why you need both types.

That fact that all you want is the segmented type, does not mean that
other people cannot find the e2e type useful.

Regards,

Gonzalo

We wish the call