[Sip] RE: Manyfolks Clarifications

["Alan O'Neill" <A.ONeill@flarion.com>]

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:Gonzalo.Camarillo@lmf.ericsson.se]
Sent: 20 March 2002 04:48
To: Alan O'Neill
Cc: sip@ietf.org
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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip