Subject: RE: [Sip] Re: Manyfolks Clarifications

From: "Alan O'Neill" <[email-masked]>
Date: Sat, 23 Mar 2002 02:01:40 -0500

Hi Dave,

Fully appreciate this, and we can also note that in the case of
pre-provisioned QoS the system uses my local 'QoS' SLA state and the
forwarding of 'current' preconditions state to the peer to also speed things
up.

So I am certainly not arguing against end to end QoS signalling but I am
trying to tease out other issues though with the use of a separate e2e tag,
and specifically worried about some of the text and assumptions voiced about
what a UA is assuming and how...

I think it would be a lot preferable if we had one integrated status model
and added supplementary tags to indicate that signalling feedback will be
provided. This avoids the local/remote v e2e beauty contest and the
inevitable risk in heterogeneous networks of multiple offers when the
offerier assumes / chooses the wrong initial status model to a prefix they
do not yet know, within commercial models that cannot guess (who pays for
booking what)

An integrated model has me booking my local, you booking your local, or
either of us booking the others local by remote signalling. If I say I can
book yours and it is not true, then the answering can come back and refuse
my offer to remotely book and instead book its own..much better I feel. No
beauty contest, no wild claims about core booking, just a negotiation of
what is possible and who books what.. All the round trip gains are still
fully available but the black holes are not..

See follow-up e-mail for details..

Thanks for trying to help us move forward on this,

Alan.

PS: By the way, the reason for the slow interactivity of this dialogue is
that I am in Aus and have just moved house so apologies for the effect that
is having in dragging this out..

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: 23 March 2002 01:15
To: 'Gonzalo Camarillo'; 'Alan O'Neill'
Cc: [email-masked]
Subject: RE: [Sip] Re: Manyfolks Clarifications

I believe the situation is much simpler than you are making out, and has
nothing really to do with resource reservation, or QoS itself. Rather,
it has to do with whether you can do a 1/2 round trip optimization in
the call establishment state machine. To squeeze this out you need to
distinguish two cases:
1) The other party has end-to-end admission control signaling, and hence
I can use local state transitions of the QoS admission control machine I
run with him to set the pre-condition satisfied state based on feedback
in the QoS signaling from the other party.
2) The other party has only "local" admission control signaling, and
hence I need to wait from them to explicitly tell me a precondition was
satisfied before entering an alerting state, rather than inferring it as
can be sometimes done in the end-to-end case.

This is not some cosmic indicator about the nature of QoS; only an
optimization knowing the nature of the other party's QoS signaling can
provide.

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gonzalo Camarillo
> Sent: Wednesday, March 20, 2002 11:57 PM
> To: Alan O'Neill
> Cc: [email-masked]
> Subject: [Sip] Re: Manyfolks Clarifications
> 
> 
> Hello,
> 
> Alan O'Neill wrote:
> 
> > The above discussion therefore suggests to me that all 
> preconditions 
> > must be assumed to be end to end, that the e2e tag for the QoS 
> > mechanism is useless because it can never be safely applied, and 
> > therefore that the e2e tag be removed.
> 
> Look at the DCS architecture. They can be sure when they have 
> e2e QoS resources. And in my intranet, when my QoS 
> reservation protocol tells me that I have e2e QoS service, it 
> is because I have it.
> 
> If you think that having e2e QoS is impossible, you should 
> provide feedback to a different WG. Not SIP.
> 
> 
> 
> > The local/remote model is on the right path but I believe 
> incomplete. 
> > Essentially, the model should be that the MN has an SLA wrt 
> QoS with 
> > some limited scope (on-net, offnet to specific prefixes etc). The 
> > caller seeking preconditions simply adds in the Invite that that is 
> > the case, and will clearly only do so if believes it has a 
> candidate 
> > SLA at its end.
> 
> Look at the 3GPP architecture. They have enough resources in 
> the backbone. The only thing that worries them is the radio 
> interface. With the local and remote tags they perform PDP 
> context activation... it works.
> 
> 
> >but the UAs should still be able to reduce
> > their preconditions to attempt a best effort call in these 
> >circumstances if  they so desire.
> 
> This is always possible.
> 
>  
> > A related issue that I would like to raise is that given that the 
> > actual IP prefix of the callee is not known at the time of 
> the offer 
> > (and hence the caller neither actually knows if it does 
> have an SLA or 
> > a QoS mech for that callee prefix), it is critical that the 
> > preconditons be able to be flexibly adjusted in response to 
> additional 
> > information.
> 
> 
> That's why you have the carry the current status in the SDP. 
> Because once you receive the first answer you can update it 
> (because you know the destination IP address)... and if you 
> required e2e QoS and after getting the remote IP address you 
> notice that it is impossible, you do not want to establish 
> the session, because your requirement cannot be fulfilled. If 
> you want, you can send a new offer without preconditions, but 
> the first offer/asnwer fails correctly, because your 
> preconditions could not be met.
> 
> > I would therefore suggest
> > that preconditions should be able to be increased or decreased at 
> > either end, and not just increased.
> 
> You can always send new offers. The only place where you can 
> only upgrade the strength tag is within a single offer/answer 
> exchange.
> 
> Thanks for your comments,
> 
> 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
> 

_______________________________________________
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: "Alan O'Neill" <[email-masked]>
Date: Tue, 26 Mar 2002 01:38:51 -0500

So a 3G node and another node outside of the 3G cloud, both of which have
segmented models on their accesses, and the same SLAs for vocie with a
common core cannot set-up voice calls with preconditions..is that what you
are saying ?

And the same for a DCS node contacting a peer outside of its cloud..

Are you sure that is the requirement and that 3G/DCS/CableLabs are happy
with that ??

Alan.

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

Hello,

> Then what should a DCS UA use to a 3G UA and visaversa ?

3G clients will use the segmented status type to speak between them. 

When a call goes outside the IMS, if 3G terminals support any e2e
protocol they can use mandatory e2e. If they don't, they simply cannot
reserve network resources towards the other end.
 
> And what should DCS and 3G use to an existing Internet host (say connected
> to Worldcom), and visaversa ?

Same as above.
 
Regards,

Gonzalo