Subject: [Sip] RE: Manyfolks draft wording

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 26 Mar 2002 01:38:55 -0500

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

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

AWO> Not what I am saying at all. If I have an SLA covering that end point
and the networks in between then I can believe but if I do not then I cannot
becasue no-one is going to book resources for me for nothing. You only
believe the e2e protocol because of other knowledge you have with the 3G
system that has an implied SLA with it. Basically, your protocol design
relies on the fact that 3G will ensure all e2e tags are adequately supported
in the core dimensioning and through PDPcontext activation in the access.
This is an SLA covering 3G and yes this will work for 3G...The general case
though is very different and hence why I am reacting to your design and the
wording in the draft.

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).
 
aWO> No - it is not a problem with the protocol at all but of the framework
because you do not in anyway cover SLAs (ie customer commitments). RSVP as
an example books resources but they can only be booked if they are available
to you from a policy perspective in the places you are trying to call..these
are SLA issues. You have written a draft that states absolutes about QoS
mechanisms that are in fact variables based on the deployment scenarion and
associated SLAs...thats all. You are therefore 3G and DCS specific and
unrepresentative of the rest of the net and how operators sell QoS..

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.

AWO> Trusting the protocol is not at issue here..The protocol does not
convey the information you require. If RSVP says there is a non-RSVP cloud
you don't know where it is and therefore do not know what to do about. If
the non-RSVP cloud is encountered within 3G you will interpret this as
success, and so you must accept all non-RSVPs as a success becasue you will
surely transition the 3G core in all VoIP cases, and you can't see if there
are additional non-RSVP congested segments..In both case, the only way to
resolve this in the gneral case is that you only trust the protocol if there
is an SLA covering the path...end of story..

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

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.

AWO> But the UA doesn't know that and it is only known in your head becasue
of what you know about 3G..ie the SLA. The reservation protocol will send
non-RSVP cloud which you choose to ignore because of that SLA commitment..

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.

AWO> That is an effect and assumption of the design and hence the root of my
concern. In the case of DOCSIS DQoS I can run bi-RSVP to the CMTS and
reserve the two accesses. In the CMTS I can have a dimensioned diff-serv
cloud into which the bi-RSVP messages are admitted. I have not used e2e
protocol but I have confirmed e2e QoS to the same level as assurance as when
using the e2e tag. The SLA with my operator to a destination says whether in
principle e2e QoS is possible. The SDP Update confirms that the QoS set-up
within this SLA has succeeded. The only difference with the signalling is
the added 0.5 RTT becasue I need to use an Update instead of the QoS
protocol feedback. The draft is missing the SLA bit and the relative
wighting of e2e v local/remote adn the associated assumptions are 3G/DCS
specific but in general bogus. Please proceed if you and the working are
happy that someone like me can in the future write a=des:QoS2 for my QoS
mechs and assumptions, and we will forget about interoperability...sound
reasonable ? (I hope not)

Alan.

_______________________________________________
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: "David R. Oran" <[email-masked]>
Date: Thu, 28 Mar 2002 11:47:08 -0500

I've reread this thread twice now, and I'm puzzled at why we seem to be
talking past each other.

Here's a little gedanken-experiment to try.

Replace every instance of the term "QoS" in the thread with "admission
control". That's what we're really talking about here; not QoS itself.

Having done that, has anything changed? Well, we certainly can stop
talking about who puts what QoS (if any) on the actual media flows. Then
we can talk (I hope) clearly about what inference one party can make
about the admission control procedures and state feedback via a QoS
signaling protocol it expects from the other party.

If that doesn't in fact help clarify anything.....back to your
regularly-scheduled program.

Dave.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alan O'Neill
> Sent: Tuesday, March 26, 2002 1:39 AM
> To: Gonzalo Camarillo
> Cc: [email-masked] '
> Subject: [Sip] RE: Manyfolks draft wording
> 
> 
> 
> 
> 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."
> 
> AWO> Not what I am saying at all. If I have an SLA covering that end 
> AWO> point
> and the networks in between then I can believe but if I do 
> not then I cannot becasue no-one is going to book resources 
> for me for nothing. You only believe the e2e protocol because 
> of other knowledge you have with the 3G system that has an 
> implied SLA with it. Basically, your protocol design relies 
> on the fact that 3G will ensure all e2e tags are adequately 
> supported in the core dimensioning and through PDPcontext 
> activation in the access. This is an SLA covering 3G and yes 
> this will work for 3G...The general case though is very 
> different and hence why I am reacting to your design and the 
> wording in the draft.
> 
> 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).
>  
> aWO> No - it is not a problem with the protocol at all but of the 
> aWO> framework
> because you do not in anyway cover SLAs (ie customer 
> commitments). RSVP as an example books resources but they can 
> only be booked if they are available to you from a policy 
> perspective in the places you are trying to call..these are 
> SLA issues. You have written a draft that states absolutes 
> about QoS mechanisms that are in fact variables based on the 
> deployment scenarion and associated SLAs...thats all. You are 
> therefore 3G and DCS specific and unrepresentative of the 
> rest of the net and how operators sell QoS..
> 
> 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.
> 
> convey the information you require. If RSVP says there is a 
> non-RSVP cloud you don't know where it is and therefore do 
> not know what to do about. If the non-RSVP cloud is 
> encountered within 3G you will interpret this as success, and 
> so you must accept all non-RSVPs as a success becasue you 
> will surely transition the 3G core in all VoIP cases, and you 
> can't see if there are additional non-RSVP congested 
> segments..In both case, the only way to resolve this in the 
> gneral case is that you only trust the protocol if there is 
> an SLA covering the path...end of story..
> 
> 
> > 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.
> > 
> 
> 
> 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.
> 
> AWO> But the UA doesn't know that and it is only known in your head 
> AWO> becasue
> of what you know about 3G..ie the SLA. The reservation 
> protocol will send non-RSVP cloud which you choose to ignore 
> because of that SLA commitment..
> 
> 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.
> 
> AWO> That is an effect and assumption of the design and hence 
> the root 
> AWO> of my
> concern. In the case of DOCSIS DQoS I can run bi-RSVP to the 
> CMTS and reserve the two accesses. In the CMTS I can have a 
> dimensioned diff-serv cloud into which the bi-RSVP messages 
> are admitted. I have not used e2e protocol but I have 
> confirmed e2e QoS to the same level as assurance as when 
> using the e2e tag. The SLA with my operator to a destination 
> says whether in principle e2e QoS is possible. The SDP Update 
> confirms that the QoS set-up within this SLA has succeeded. 
> The only difference with the signalling is the added 0.5 RTT 
> becasue I need to use an Update instead of the QoS protocol 
> feedback. The draft is missing the SLA bit and the relative 
> wighting of e2e v local/remote adn the associated assumptions 
> are 3G/DCS specific but in general bogus. Please proceed if 
> you and the working are happy that someone like me can in the 
> future write a=des:QoS2 for my QoS mechs and assumptions, and 
> we will forget about interoperability...sound reasonable ? (I 
> hope not)
> 
> Alan.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>