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

From: William Marshall <[email-masked]>
Date: Thu, 25 Oct 2001 08:50:18 -0400 (EDT)

> 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.

All of the content needed for such a section is already contained in
the introductory and overview sections of the I-D.  I see no reason
to duplicate it (the draft is already long enough), or to generate 
another I-D and increase the workload on all of us.

The main point is that call blocking happens, and call defects are bad,
and carriers need to distinguish them (unless the blocking rate is so 
low - but companies that built that much spare capacity have gone under).

I believe all the other comments have been already addressed by others.

Bill Marshall
[email-masked]

-----original message-----
From: Juha Heinanen <[email-masked]>
Date: Thu, 25 Oct 2001 09:29:30 +0300
To: Rakesh Shah <[email-masked]>
Cc: "SIPWG Mailing List ([email-masked])" <[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
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

_______________________________________________
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: William Marshall <[email-masked]>
Date: Fri, 26 Oct 2001 11:08:08 -0400 (EDT)

After another careful reading, I have one of my own last call 
comments to make on this draft.

in section 11.3 (Behavior of Destination) 7th paragraph states
 "When procesing of all preconditions is complete, if a precondition
  in the initial INVITE specified a confirmation request, the UAS MUST
  send a COMET message to the UAC ..."

This should be changed to "a precondition in the SDP specified ..."
in order to cover both the offer SDP contained in the initial INVITE
and (when an offer SDP was sent by the UAS in the 183) the answer SDP 
contained in the PRACK.

Bill Marshall
[email-masked]