Subject: [Sip] Manyfolks draft wording

From: "Alan O'Neill" <[email-masked]>
Date: Fri, 22 Mar 2002 22:23:15 -0500

Page 7 top

            ' Note that the use of the segmented status-type does not
             prevent bottlenecks in the backbone, only in the access
             networks.'

The wording here is inappropriate as it seems to suggest that e2e is somehow
different and more to the point better, than local /remote but this is
clearly not universally true. 

For local/remote tags
I can run independent bidirectional RSVP/DOCSIS/PDP context QoS sessions
over two accesses to the UAs local cores, and then have preprovisioned
backbone sufficient for call load betwen those cores.

For e2e tags
I can run RSVP end to end through access-core-access and again will use a
pre-provisioned core for the call load. 

In both cases, both UAs will get feedback from the admission control attempt
into the core bandwidth. In both cases if the core is not pre-provisioned,
or no admission control is undertaken into the core then bottlenecks in the
core cannot be prevented. The statement is therefore deployment specific and
should be rectified.

_______________________________________________
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: Sat, 23 Mar 2002 19:55:59 +0200

Hello Alan,

> clearly not universally true.

I find the wording perfectly OK. Again, you are confusing the QoS
mechanism with the preconditions.

Having local/remote preconditions does not prevent bottlenecks in the
network. It may happen that you have a high bandwidth channel between
both UAs, and it may happen that you have a low bandwidth link in the
middle, but in both situations, this has nothing to do with the
preconditions you use. Your local/remote preconditions do not tell you
anything about the backbone.

Using an e2e reservation protocol ensures you that there are network
resources end to end. If the protocol does not work because it allows
routers to claim that there is QoS when there is not, it is a problem of
the reservation protocol. Not a problem of the preconditions.

The idea of manyfolks is separating the reservation mechanism from the
preconditions. If RSVP (or anu other e2e reservation protocol) does not
work, you should send feedback to its authors, not to the authors of
manyfolks.

Thanks for your comments,

Best regards,

Gonzalo