Subject: [Sip] Manyfolks Clarifications

From: "Alan O'Neill" <[email-masked]>
Date: Tue, 19 Mar 2002 23:12:46 -0500

Hi Gonzalo,

Firstly, just wanted to say that the draft now looks significantly better
given the inclusion as requested of desired and current status, separation
of direction-tags in offers when necessary, as well as specific rules for
agreeing lead roles. This makes the preconditions exchanges so much more
efficient now although I am a little disappointed that my contributions in
this regard have not been acknowledged. 

The draft is also now much clearer in many areas as to what actually
happens, and when, so good job there from an editing perspective.

However, there still appears to be major confusion left in the area of the
e2e v local/remote tags, and what state the UA uses in deciding which to
use. Ideally, the aim is that preconditions, whilst trying to couple SDP
with QoS mechanisms, is independent of those mechanisms. 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. I cannot from the draft unambiguously identify what those
rules are and I believe much of the feedback related to the status tags is
due to this confusion.

To try to tease out the state and rules I have listed below some QoS
scenarios Gonzalo and I would appreciate it if you could let me know how
each UA should act in each case,  assuming correct protocol by all elements,
by stating which status tag should be used and how the UA knows to use that
tag (ie what state is interrogated). By all means just initially put the
testcase numbers and letters under either local/remote or e2e columns and
I'll follow up with specific queries about why and how (what UA state
triggers the decision). 

First some terminology..

end to end : UA to UA
access: customer router to first core router
LAN: bandwidth rich network between UA and access
core: first to last core router including arbitrary transit domains and
associated QoS mechanisms
banana: any hop by hop QoS protocol that triggers admission control checks
at each hop
non-banana cloud : a sequence of n routers that do not process banana hop by
hop QoS protocol messages
banana-diff edge : a router at which banana triggers admission control
checks into a diff-serv BA (aggregate)
banana-null edge : a router at which banana triggers admission control
checks into the next link only
diff cloud: a sequence of routers between two banana-diff edges where
aggregate resources exist
null cloud: a sequence of routers between two banana-null edges where
available resources are unknown

Test Cases

Assume in all cases that banana carries information as to whether a non-RSVP
cloud was traversed and also carries admission control success or failures
between the two banana end points. In each case please indicate if the
preconditions will be satisfied if banana indicates a non-banana cloud with
an admission control / reservation success (it is obvious they will not be
met if any admission control failure is reported)

1. Network Topology UA-access-core-access-UA

a) End to end banana where core is a diff-cloud
b) End to end banana where core is a null-cloud
c) UA to core banana at both ends with banana-diff edges into a diff-serv
cloud
d) UA to core banana at both ends with banana-null edges into a non-banana
cloud
e) end to end banana with a non-banana cloud on one access with banana-diff
edge at core access router
f) end to end banana with a non-banana cloud on one access with banana-null
edge at core access router
g) UA to core diff clouds at both ends with banana trunk across the core
with diff-banana edges
h) end to end banana where no core element speaks banana (ie one big
null-cloud)
i) end to end banana where no core element speaks banana (ie one big
diff-cloud)

2. Network Topology UA-access-access-UA (no core cloud due to common
access-core router)
c) to i) above with missing cloud

3. Network Topology UA-LAN-UA
a) end to end banana with no LAN QoS (null-could)
b) end to end banana with LAN QoS (diff-cloud)
c) end to end banana with one UA not supporting banana

4. Network Topology UA-LAN-access-core-LAN-UA (on gateway)
a) end to end banana with non-banana cloud between core-LAN-UA
b) UA to core banana where core is diff-serv cloud with a banana-diff edge
c) UA to core banana where core is null-cloud
d) null-cloud UA to core with core to gateway banana trunk and null-banana
edge
e) diff-cloud UA to core with core to gateway banana trunk and diff-banana
edge

The objective here is to identify how much the UA is relying on information
in its SLA, on its available QoS mechanisms, on its topology awareness, and
on feedback from SDP preconditions and QoS mechanisms. I may need to use
additional examples to further tease out what is known and what is assumed
by the UA to correctly use e2e v local/remote tags... I am not suggesting we
need to explore and document all scenarios but I think we do need to
identify and definitively document the distinguishing characteristics and
state so that an implementor and two peer UAs on different ISP networks will
do the right thing in all cases...

Gonzalo - feel free to alternatively state the definitive distinguishing
characteristics, UA state and non-banana cloud interpretation as you see
them, rather than going through the test cases, if you feel they are already
clear..and I am simply misunderstanding the architecture..

Regards,  Alan.

Acknowledgements
I'd like to thank Xin Chen for the generic banana QoS signalling framework
:-)

_______________________________________________
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: Wed, 20 Mar 2002 06:48:11 +0200

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

For example, if I have an end to end protocol that tells me that there
are resources end to end, I can use the end to end tag. However, if I do
not have a way of knowing that there are end to end resources and I use
the e2e tag, I will be locked for ever, because I cannot know anything
about the current status.

About DiffServ and SLAs: Let's assume I call you and I know that you are
connected to the same DiffServ network as I am connected and that this
network will always provide a certain QoS to my marked traffic. I also
know that you are on a 100 based-T ethernet. Then, I can set the current
status to e2e sendrecv even before sending my INVITE... but the problem
is that, before making the call, you do not typically know in which
terminal you are going to be available. That's why you will typically
need an end to end QoS reservation protocol.

> a) End to end banana where core is a diff-cloud

I do not think this examples are going to be helpful to understand the
problem. Again, if banana tells you when e2e QoS has been achieved, you
can use e2e. If not, you cannot.

> b) End to end banana where core is a null-cloud

The same as above.

> c) UA to core banana at both ends with banana-diff edges into a diff-serv

Again, if you has any means to know whether the other end is connected
to the same DiffServ cloud as you and you are also sure that both the
callee and the caller have SLAs with the cloud, you could use e2e. If
you do not know that, you cannot use e2e.

> d) UA to core banana at both ends with banana-null edges into a non-banana

The same as above.

> edge at core access router

The same as in every single bullet. If banana tells you that there is
end to end QoS, you can use e2e.

> f) end to end banana with a non-banana cloud on one access with banana-null

Same as above.

> h) end to end banana where no core element speaks banana (ie one big

I do not think it is worthwhile going on with this specific cases. I
have explained the general rule above. I believe that the
missunderstanding comes from trying to mix the actual QoS protocol with
manyfolks.

Here we define preconditions. Other WGs define QoS protocols. Therefore,
if your banana messages traverse a non-banana cloud and cannot ensure
that there is QoS, too bad. But it is a problem related to the QoS
protocol, not to manyfolks. Fix banana or make every core system support
banana and you have your problem resolved. You can also implement
gateways and a discovery mechanism or whatever you want, but this is not
a problem related to the preconditions.

> on feedback from SDP preconditions and QoS mechanisms.

You rely on any information you have. If by inspecting the remote
contact header I am sure that you are in the same ethernet as I am, I
will be able to set current status to sendrecv.

To give you a more radical example of the information you can use, I can
call you and you are in the same office as me. Since I see that your
ethernet cable is connected to the same hub as mine, I can set the
current status to sendrecv.

Regards,

Gonzalo