Subject: [Sip] RE: Manyfolks draft wording

From: "Alan O'Neill" <[email-masked]>
Date: Mon, 25 Mar 2002 06:37:25 -0500

Gonzalo,

I hope this is simply the result of language difficulties... 

I stated that "e2e reservations do not 'necessarily' ensure end to end QoS".
This naturally implies that they can, but not always do, ensure end to end
QoS. They ensure it when every pinch-point between the two endpoints process
the e2e QoS signalling, undertake admission control and book sufficient
resources for the flow. They do not in anyway ensure it when only the two
end points run the e2e protocol but none of the routers do (the general
Internet today). Some middle ground whereby the access does and the core
doesn't process the end to end signalling is the common case and then the
core does not ensure QoS, it merely provides some statistic possibility of
there being resources based on the operator dimensioning, commensurate with
the SLA with customers and between providers.

In the manyfolks draft and in your follow-up to my wording issue you state
that segmented does not ensure QoS whilst e2e protocol does. Thereby you are
stating that segmented is somehow less able to satisfy preconditions and
hence, according to my concern, is considered worse in this specific regard.

The draft should leave the subject, and relative merits, of how operators
provide and ensure QoS to them. They can use pre-provisioned, segmented, e2e
and combinations, with suitable dimensioning risks (call blocking v call
degradation probabilities) for the commercial model.

e2e does have characteristics that are different and beneficial in some
respects at the cost of running signalling. One such benefit was raised by
Dave Oran and there are others...but that is not the point at hand.

Please remove the misleading and frankly incorrect text.

Alan.

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 24 March 2002 01:31
To: Alan O'Neill
Cc: [email-masked] '
Subject: Re: Manyfolks draft wording

Hello,

Alan O'Neill wrote:

> You keep stating that using an e2e protocol guarantees end to end
resources
> but that is not necessarily true.

as I have already stated, if you think that e2e reservation protocols do
not ensure e2e QoS, you should provide your feedback to a working group
that is chartered to develop e2e reservation protocols. Not to SIP.

The fact is that, when you use e2e reservation protocols, you need
certain information in the signalling plane. This information is
different when you use a reservation protocol only in the accesses. 
Different tags ensure that SIP carries the information needed by the
resource reservation mechanism in use.

If you think that people should not be using e2e reservation protocols
because they do not work, you should address your feedback to the
persons developing network architectures. Not to SIP.

> e2e is not better than segmented per say..

Who said that e2e is better or worse than segmented? They are just
different because they apply to different scenarios. If you think that
one of them is always better than the other, you should address your
feedback to a working group developing resource reservation protocols.
Not to SIP. This way they would not lose their time on something that is
clearly worse than another already existing mechanism.

Regards,

Gonzalo

_______________________________________________
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: Mon, 25 Mar 2002 16:19:09 +0200

Hello,

> I stated that "e2e reservations do not 'necessarily' ensure end to end QoS".

Yes, we have been speaking about this for a while already. What
manyfolks provides you is a hook between the application and the
reservation protocol. 

When the reservation protocol is an e2e protocol (e.g., RSVP), you need
to know when the send and the recv directions are ready in order to
resume session establishment.

This framework assumes that when the reservation protocol says that the
send direction is ready, it is true. What you are saying is that the
framework should say: "when the other end tells you that the send
direction is ready, don't believe it, because it is not necessarily so.
e2e reservation protocols do not work, so the other end is missinformed
when he states that resources in the send directions are reserved."

What I am trying to say is that the fact that e2e reservation protocols
may not ensure e2e QoS is not a problem of the framework but a problem
of the reservation protocol itself. The manyfolks framework should not
describe whether reservation protocols work or not. It only transports
the information the resource reservation protocols provides (that is,
the status of resource reservation as seen by the resource reservation
protocol).

Take into account that if you want preconditions to work, you have to
trust the reservation protocol. If you receive a messages saying: "I
have reserved resources in the send direction", and you do not trust it,
preconditions are useless. Since you could not be sure whether or not
the preconditions were met, you would never resume sessione
establishment.

> hence, according to my concern, is considered worse in this specific regard.

If you use e2e status type, there is something in the SDP that tells you
that there are e2e resources. As I said before, manyfolks assumes that
you trusts your reservation protocol.

when you use local/remote tags, there is nothing in the SDP that tells
you anything about the backbone. Therefore, there may be resources or
there may not be resources. The fact is that with the information in the
SDP you cannot tell.

Let me give you an example. I can say that the use of segmented
preconditions do not ensure that today is a sunny day. You may claim
that you are using segmented preconditions and that the day is very
sunny, but the fact is that the information in the SDP does not tell you
anything about the weather nor about resources in the backbone.
Therefore, when you use the segmented status type, there may be
resources in the backbone, or there may not be resources in the
backbone. And the same way, it may be a sunny day, or it may rain.

> degradation probabilities) for the commercial model.

the draft does not give any advise about commercial models. As I already
stated, there are organizations using both status types.

Best regards,

Gonzalo