Subject: [Sip] RE: Manyfolks Clarifications

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 20 Mar 2002 18:32:15 -0500

Hello Gonzalo,

The reason behind stating the examples was to expose the flaws in the e2e v
local/remote tags...so some additional discussion needed.

Firstly, an obvious statement is that all preconditions must be e2e because
the unavailability of resources at any point in the path damages the end to
end flow. The SIP layer is the only layer that can be assumed to go end to
end and is hence why precondition processing should be at the SIP layer.. we
agree to that I assume..

Secondly, a less obvious statement is that all QoS protocols are segment by
segment because even if the QoS protocols themselves go end to end,
resources are only granted hop by hop and segment by segment based on local
policy checks and agreement to allow the QoS protocol to interact with the
network layer schedulers and undergo admission control. The UA doesn't know
any of this and must not / cannot treat end to end signalling as some kind
of magic...For example I can have a diff-serv SLA with a specific
destination that is as strong a guarantee as any end to end protocol.

RSVP for example can go one hop only from the host at both ends over their
access links. Alternatively it can go end to end but bypass and not interact
with any of the routers on the path. It can go end to end but only interact
on one half of the path or finally it can go end to end and interact with
all routers. The UA either sees RSVP end to end, RSVP over part of the path,
with in either case the possibility of a non-RSVP cloud over an unknown
portion of the RSVP path. The UA cannot know any of this and in fact doesn't
even know the whereabouts of the SIP endpoint until SIP routing is
completed. It cannot discover the non-RSVP cloud until feedback has been
given and it never knows the impact of that cloud because it cannot know
whether the non-RSVP cloud is a black hole or a dimensioned diff-serv cloud.
The only thing the UA knows is whether its SLA supports SIP multimedia to
specific prefixes.

One potential way out of this mess might be to refer back to your clear
statement below of when the UA can use the e2e tag. I believe I can
interpret your statement to mean 'if the caller has a QoS SLA that covers
the callee, independent of how that SLA is invoked in the form of network
resources, then it can add the e2e tag'. Even then though, the callee prefix
is not known until the response is received at the caller and so the caller
can never safely add the e2e tag in the Invite. The callee can of course add
it on receiving the Invite.

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. All QoS mechanisms should be assumed to be segment by segment and
we need to have tag names defined in the preconditions signalling to
exchange who can, and agree who should, do the resource booking. This gives
maximum isolation from the actual QoS mechanisms. 

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. The
preconditions therefore are automatically a request to see if the other end
also has an SLA with its provider in the directions requested. How those SLA
resources are accessed is in principle out of scope except that one end
might have the SLA to allow resources to be accessed (the policy bit) but
that resources need to be booked by the other end, such as in the case of
RSVP. We therefore need a supplementary tag to indicate this requirement.
When the callee/caller sees this supplementary tag it can either act on that
request if it knows how to (configuration, experience, trial and error or
mechanism specific tags) or it can refuse because it is either incapable, or
unwilling to act on the other ends behalf. This is perfectly reasonably
because if a MN has an SLA for SIP QoS to specific prefixes, then it is
reasonable to expect that the operators have arranged for those resources to
be accessable by including information of which mechanisms to use for each
prefix. If these have not been arranged then the UAs must assume the
preconditions cannot be met, but the UAs should still be able to reduce
their preconditions to attempt a best effort call in these circumstances if
they so desire. Note here that one reason a capable UA might refuse to
remotely book the resources is because the person who books might be the one
who is charged so a caller could in effect be asking for a reverse charge
stream which a callee must be able to legitimately refuse. 

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. I would therefore suggest
that preconditions should be able to be increased or decreased at either
end, and not just increased. Non-logical increases and decreases should not
be allowed though to avoid 'hunting'. The aim should be to 'converge' on an
agreed precondition once the endpoints are identified and SLAs, QoS mechs
and available resources confirmed. The precise rules will need some work
though.

The one remaining addition for this architecture in my opinion is to try to
find a way to automate the discovery of what preconditions are possible to
specific destinations and to increase the segment granularity of the QoS
SLAs. This can only be done at the SIP layer and requires additional SIP
smarts. I have already done some work on this and will write it up in a
draft in a couple of months time once present load is out of the way. I
think this can be cleanly separated from the manyfolks draft which
essentially only deals with two local arbitrarily sized access segments that
only provide end to end guarantees if the segments overlap or at least meet
at a common edge...

Hope this takes us forward Gonzalo...

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

Hello Alan,

> Ideally, the aim is that preconditions, whilst trying to couple SDP
> with QoS mechanisms, is independent of those mechanisms.

Yes, that's the idea.

> However, with the
> two choices available to the UA (e2e or local/remote) status types the
draft
> needs to be very clear about the state and rules used by a UA in inserting
> those status tags.

The rule is: if you have a way of knowing that there is end to end QoS,
you can use e2e. Otherwise you would never know whether there is
actually e2e QoS or not.

_______________________________________________
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: Thu, 21 Mar 2002 06:56:36 +0200

Hello,

Alan O'Neill wrote:

> removed.

Look at the DCS architecture. They can besure 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.

> 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
> they so desire.

This is always possible.

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

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 22 Mar 2002 20:15:14 -0500

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

> 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.
> 
> 
> 
> > 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.
> 
> 
> > 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.
> 
> > 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.
> 
> 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 20:07:20 +0200

Hi,

> optimization knowing the nature of the other party's QoS signaling can

Exactly. That is the spirit of the draft. Separating the QoS, security
of whatever mechanism you use to meet the preconditions from the
information that needs to be carried in SIP in order to know when to
proceed with session establishment. However, as Dave points out, the
information to be carried in SIP depends on the mechanism used below.
That's why we have both status types: segmented and e2e.

Regards,

Gonzalo