Subject: [Sip] Manyfolks version 04

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Feb 2002 05:03:07 +0200

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

---

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

Well, although we shared some of the view, I still think manyfolks is useful
but only for the side which needs precondition. Becuase it may take some
time for the user to setup the access network QoS, precondition can make
sure that the other side will wait for such a period of time.

Thanks

Xin Chen

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

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

Chen, Xin (Xin) writes:

 > In 3GPP network, local QoS (caller) + Differv in the core + local QoS
 > (callee) = end to end

even if i'm not any fan of 3gpp, the above is what i have advocated on
this list several times and have thus questioned manyfolk's usefulness.
because it is safe to assume that access is the only bottleneck in most
networks, manyfolk becomes nothing more than unnecessary overhead.  rsvp
is one of those DoA ietf creations and i don't see it raising from death
with the help of sip either.

-- juha

---

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Wed, 27 Feb 2002 11:34:02 -0000

First, if you want to use "e2e", "local" or "remote", please give a
reference in reference section which gives clear definition on what is end
to end QoS. What is the criteria for meeting the requirements of end to end
QoS and what is the cirteria for local QoS. We can not talk about this
without even knowing what "end to end QoS" really mean! Or alternatively,
clear written in this draft what does this draft mean on "end to end QoS"
and "local QoS". The offerer and answerer have to share the same view on
those difinitions, otherwise, manyfolks will not work as what it is written
now.

See more commment inline please,

Xin Chen

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

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 26 February 2002 20:14
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:
> 
> Hi Gonzalo,
> 
> You can only ask and wish there will be e2e QoS on both directions and you
> can not make sure of this, becuase you always rely on the confirmation
from
> other party and you have to trust it! 

What is the problem trusting the other party? You also trust that the IP
address that you receive in the offer is his real IP address, and that
he is listing the codecs he really supports, etc...

[XC]Yes, you always trust the IP address of the other end, becuase you know
you can not restrict how the other end to choose the IP address. And here,
in manyfolks, you still aways trust the confirmation from the other end on
the QoS condition, but you mandate how the other end to meet the condition. 

>According to my understanding, SIP is
> a protocol not used for QoS reservation and it is independent to any QoS
> reservation protocol, basically I can configure my SIP terminal to accept
> any offer having "a=des:qos mandatory e2e sendrecv" even if my terminal
> doesn't not support any QoS reservation protocol and I can still claim
that
> it is a terminal supporting manyfolks, because you can not say that my
> terminal is not manyfolks supported simply because I don't support an end
to
> end QoS reservation protocol.

Well, I can build a SIP terminal that receives INVITEs, generates a 200
OK with a correcty formed session description, but that does not alert
the user, and does not play the media received thru the speakers, and
does not even turn on the mic... it would be a correct SIP
implementation from the syntax point of view, but I would be violating
the protocol, because the messages I am sending do not reflect what is
really happening...

This is what you are proposing to do...
[XC]No, what I am proposing is: Don't use the status type at all. An offer
just indicates the desire for QoS, and when another side receives the offer,
it will do its best to meeting the QoS condition. If it can do RSVP, then it
is fine, if it can not, then it will have other means to do that. If the end
user thinks that the qoS is done, it sends you the confirmation. If it can
not, it refuses the offer. It is just as simple as this, and this is also
all SIP can do. Again, I have to say: SIP MUST NOT be able to tell you
whether there is an end to end QoS or not. If it can, SIP is a QoS
reservation protocl. All SIP can do in this case is to tell the other end
what I wish to have, but regarding how are you going to do (RSVP, Diffserv
or whatever) to meet the requirements, SIP doesn't care. 

> If you can, then this draft does tide SIP up
> with QoS protocol.

Well, that's exactly the idea behind the draft. Until QoS is not
provided, the user is not alerted...
[XC]I agree with this. But who is going to judge whether the QoS is provide
or not? Let the terminal to juge this, not SIP!
 
> Simple question: What is the "end to end", where is the definition of end
to
> end QoS?

OK, you are the caller. How can you know that there is QoS beyond your
DiffServ router?? 
[XC]Yes, I know. It is written in the contract between me and my ISP.

You can only know that if you use the segmented type
(the callee will tell you when he has QoS on his access network).

You use the end to end type when you can be sure that there is QoS end
to end (e.g, RSVP).
[XC] This is not correct. RSVP can also be used for local network QoS setup.
I can have the RSVP messages terminated on my eggress router of the local
network and the eggress router has a link to the Differv domain for the rest
of the network. Therefore, even a terminal is using RSVP, it is still not
sure it is doing the end to end or not according to your understanding that
RSVP = end to end!

Thanks

Gonzalo

> 
> In manyfolks, RSVP = end to end
> 
> Which one is right? I think both are correct depending on the practical
> situation. The only difference is that in 3GPP network, Differv is
> pre-agreed based service level agreement, therefore, the user is not aware
> of that. And for RSVP, the user is aware of that. This is the only
> difference. But the 3GPP terminal's call will suffer the failing simple
> becuase of this difference if we use those parameters like "e2e" in SDP.
> 
> I hope you will not think that I am being aggressive because I really see
> some hint in this draft to give the definition on what the end to end is
and
> what the local and remote is regarding on QoS reservation and we should
not
> do this. I don't want to hear one day a SIP developper says:"Becuase SIP
> says this, therefore, we have to use the QoS reservation protocol."!
> Bascially, SIP should not give any restriction on the terminal's
> understanding on what end to end QoS.
> 
> Thanks
> 
> Xin Chen
> 
> Lucent Technologies
> Tel: +44 1793 883137
> Mobile: +44 7799 034668
> 
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 26 February 2002 10:20
> 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,
> 
> > > 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!
> 
> 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
> > 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
> > >
> > > 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,
> > >

---

From: [email-masked]
Date: Wed, 27 Feb 2002 14:29:56 +0200

William Marshall writes:

 > Which is more DoA - rsvp or bandwidth brokers?

both are equally DoA.  when you choose your service provider, make sure
they peer with right guys and prioritize your media packets over
bottleneck links (if any).

-- juha