Subject: RE: [Sip] Manyfolks version 04

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

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! 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. If you can, then this draft does tide SIP up
with QoS protocol. 

Simple question: What is the "end to end", where is the definition of end to
end QoS?

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

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

-----Original Message-----
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
> >
> > -----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]

-- 
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: [email-masked]
Date: Tue, 26 Feb 2002 21:47:21 +0200

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

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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Feb 2002 22:14:11 +0200

Hello,

"Chen, Xin (Xin)" wrote:
> 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...

>According to my understanding, SIP is
> 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...

> 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...
 
> In 3GPP network, local QoS (caller) + Differv in the core + local QoS

OK, you are the caller. How can you know that there is QoS beyond your
DiffServ router?? 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).

Gonzalo