Subject: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt

From: Rakesh Shah <[email-masked]>
Date: Wed, 24 Oct 2001 18:52:28 -0400

Just a reminder to this draft's reviewers to post their reviews to the list.

The last call discussion has been opened on the list and is due to close on
12Nov01.

Regards,
 
Rakesh
______________________________
Mr. Rakesh C. Shah
Project Coordinator
dynamicsoft Inc.
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
(973) 952-5000 main
(973) 952-5066 direct
(201) 214-6084 mobile
(973) 952-5050 fax
[email-masked]
www.dynamicsoft.com

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Thu, 25 Oct 2001 09:29:30 +0300

as a general comment i have to say that the idea of interleaving an
end-to-end resource reservation mechanism with sip signaling sounds an
overkill that will introduce lots of new complexity, delay, and
processing in the network devices to the call setup process.  i thus
wonder if it will ever be deployed in practise in any large scale.

lets consider cellular calls as an exaple, which is likely to be the
environment, where the reseource problem will be the greatest.  there we
don't need any end-to-end reservation protocol, such as rsvp, to check
that the resources are available.  the calling party can simply first
try to create a new real time pdp context for the call and if that
succeeds, he knows that local resources are available.  when the invite
hits the called cell phone, it too tries first create a new real time
pdp context for this call and if that succeeds, the phone will ring and
an ok will be send back to the calling party. the packets will then be
marked with a diffserv code point indicating that they should use the
real time pdp context.

some of the details are missing from the above example, but it should
serve to illustrate my point.  the question thus remains, do we really
need in real life the complexity of manyfolks-resource?  if it is likely
that other solutions might also work and be widely deployed, the i-d
should say so.  otherwise readers might get the impression that this is
THE way to implement qos for sip calls.

may be i missed it, but the i-d should also try to analyze if the
mechanism will scale if every phone call in the world would use it and
how much additional delay will be introduced by it to the call setup
process.

-- juha

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 25 Oct 2001 11:56:18 +0300

Hi:

I'm not sure if I shout this comment publicly, but just in case I didn't, here it goes:

Manyfolks should clearly state that the SDP returned in the 200 OK for the INVITE MUST NOT be used to change the "agreed" SDP negotiated in the INVITE,
183 (and PRACK) process. The SDP in the 200 OK MUST be sent to allow backward
compatibility of middle proxies, but not to change the SDP itself.

If such a change is needed, the UA should re-INVITE.

I hope this clarification is acceptable and can be incorporated to the text.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 25 Oct 2001 12:06:56 +0300

Miguel A. Garcia writes:

 > What IETF has to do is to publish standards that are general enough to
 > have enough support. In this case, the manyfolks draft is already in
 > use by PacketCable networks, and planned to by used by 3GPP networks.
 > I think this is enough support to publish this standard.

i didn't say that you should not publish it, but that it currently lacks
an applicability statement and evaluation of its effects on call setup
delay and network resource utilization.

 > Note that I don't want to discuss why 3GPP has adopted the mechanisms in
 > manyfolks in this mailing list.

i met yesterday a person who works for a big mobile phone/network vendor
and when i asked about manyfolks, he said that the 3gpp indeed has
adopted it, but that it is not a mandatory part of the spec and that
this vendor has no intention to use it in its own products.

-- juha

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 25 Oct 2001 11:52:14 +0300

Hi Juha:

I must say that I disagree with your words.

First of all, the IETF is the standards protocol factory. I don't think
you and me have the right to judge whether a protocol will be a success 
or a failure. Time will judge this aspect.

Secondly, I disagree with your interpretation of manyfolks in 3G networks.
There has been a lot of discussions in 3GPP that have proved that manyfolks
is useful to establish a PDP context before the remote party rings. The
use of resource reservation may be applied to the PDP context in 3G, rather
than RSVP (like in PacketCable). 

Note that I don't want to discuss why 3GPP has adopted the mechanisms in
manyfolks in this mailing list. I think it is of no use to the SIP community.
It has been long discusse in 3GPP meetings, so no way to re-start the 
discussion here.

/Miguel

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 25 Oct 2001 12:40:50 +0300

> delay and network resource utilization.

This sounds like another internet draft on the applicability statement of the manyfolks draft. *If* such a document is needed, I would like to have it separated from the manyfolks standards track document.

> this vendor has no intention to use it in its own products.

Good luck to that vendor. I can tell you that manyfolks IS mandatory in 3GPP, so if somebody designs a terminal that does not support manyfolks, is not going to be 3GPP compliant. I believe the person you spoke to is miss-informed.

/Miguel

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 25 Oct 2001 12:50:52 +0300

> Good luck to that vendor. I can tell you that manyfolks IS mandatory in 3GPP, so if somebody designs a terminal that does not support manyfolks, is not going to be 3GPP compliant. I believe the pe…

may be the person was misinformed.  i thought that he wasn't, because he
was giving a talk in an ip qos conference regarding 3g qos.  anyway, i
as a mobile network user definely don't want to pay for that extra
signaling traffic.  there better thus be an option to turn manyfolks off
in the 3gpp phone.  

another option of course is that i don't use your protocols at all, but
just plain sip.  the more i hear what is going on in the 3gpp standars
process, the more likely that schenario becomes.  looks like there is
noone paying the bill involved in the 3gpp process.

-- juha

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 25 Oct 2001 10:40:21 -0500

Agree 100% with Juha and would like to add that for the more general
interdomain model (expired drafts in the SIP
http://www.softarmor.com/sipwg/) we showed call flows with SIP and RSVP
with up to 40+ messages, too complex, unless they are very expensive
video calls with high bandwidth reservations. Phone calls could just do
with best effort or DiffServ at the most. I suppose in an emergency,
making QoS a precondition makes no sense anyway IMHO.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juha Heinanen
> Sent: Thursday, October 25, 2001 1:30 AM
> To: Rakesh Shah
> Cc: SIPWG Mailing List ([email-masked])
> Subject: [Sip] Last Call - draft-ietf-sip-manyfolks-resource-02.txt
> 
> 
> as a general comment i have to say that the idea of 
> interleaving an end-to-end resource reservation mechanism 
> with sip signaling sounds an overkill that will introduce 
> lots of new complexity, delay, and processing in the network 
> devices to the call setup process.  i thus wonder if it will 
> ever be deployed in practise in any large scale.
> 
> lets consider cellular calls as an exaple, which is likely to 
> be the environment, where the reseource problem will be the 
> greatest.  there we don't need any end-to-end reservation 
> protocol, such as rsvp, to check that the resources are 
> available.  the calling party can simply first try to create 
> a new real time pdp context for the call and if that 
> succeeds, he knows that local resources are available.  when 
> the invite hits the called cell phone, it too tries first 
> create a new real time pdp context for this call and if that 
> succeeds, the phone will ring and an ok will be send back to 
> the calling party. the packets will then be marked with a 
> diffserv code point indicating that they should use the real 
> time pdp context.
> 
> some of the details are missing from the above example, but 
> it should serve to illustrate my point.  the question thus 
> remains, do we really need in real life the complexity of 
> manyfolks-resource?  if it is likely that other solutions 
> might also work and be widely deployed, the i-d should say 
> so.  otherwise readers might get the impression that this is 
> may be i missed it, but the i-d should also try to analyze if 
> the mechanism will scale if every phone call in the world 
> would use it and how much additional delay will be introduced 
> by it to the call setup process.
> 
> -- juha
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>