[Sip] Manyfolks Clarifications

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

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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip