[Sip] Re: Manyfolks Clarifications

[Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>]

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.

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.





> 1. Network Topology UA-access-core-access-UA
> 
> 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
> cloud

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.

> cloud
> e) end to end banana with a non-banana cloud on one access with banana-diff
> 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.

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

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

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

_______________________________________________
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