Subject: Re: [Sip] Re: Manyfolks: the segmented approach

From: [email-masked]
Date: Fri, 15 Mar 2002 18:53:13 +0100

Hi Gonzalo,

Concerning your first comment:
When I send you a SIP INVITE, I have no knowledge about where you are
connected (ADSL, UMTS, etc.), therefore I have no idea on the procedures
that you have to perform on your access network, but anyhow, I'm always
looking for full end-to-end QoS.
Therefore, my understanding of the segmented approach is that I'm telling
you that I will not send you messages using a protocol that has to be
understood in the backbone (e.g., RSVP), but I'm asking you to do what is
required for resource reservation in your access network, if ever you need
to do something (but I don't know if you actually need to do something, and
I don't care about, I'm only interested in the final result).
Is this right in your point of view ?

Concerning your comment about the example:
Maybe I misunderstood something, but my understanding is that end-to-end
means "full end-to-end", that is from end-user to end-user, and in this
case, when I use the tag e2e, I'm asking the backbone to do what is
requested, but I'm asking you also to do what is needed in your access
network.
In other words, my understanding is:  segmented means maybe to do something
on both access networks only, but not  in backbone; end-to-end means to do
what is needed in the backbone and in both access networks.
But maybe I'm wrong. If the tag e2e does not take into account both access
networks, then you should not say "end-to-end" but maybe "edge-to-edge". I
prefer by far the first approach.

Best regards
Juan Carlos

Gonzalo Camarillo <[email-masked]>@ietf.org on
15/03/2002 18:27:44

Sent by:  [email-masked]

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
cc:   [email-masked], [email-masked]
Subject:  [Sip] Re: Manyfolks: the segmented approach

Hi,

inline:

[email-masked] wrote:
>
> Hello,
>
> The segmented approach defines two tags: local and remote. Are they both
> really needed ?
> I have the feeling that a single value should be enough, let's say
"local".

Yours is a valid point of view. However, the point of view of the draft
is slightly different. Let's say that I am in a 3G network. I know that
the backbone is not a problem, but the radio interface is. Therefore, I
want the callee to establish the proper PDP context for this call. I can
ask him to do that by using the remote tag.

In the next call I migh care only about my access, but it is OK if the
callee does not reserve resources in his access network. In this case,
as you suggest, you would only need the local tag.

Therefore, your proposal would cover the second call, but not the first.
And I believe that I have the right to say that if the other end does
not reserve resources in his access I do not want to talk to him... you
could claim, that the other end could tell you that he has reserved
resources when he ha not really done so, but, as I said, that would be a
non-compliant UAS.

>
> For the desired-status, you only need to say "I'm using the segmented
> model", that is, I will not send you e2e resource reservation messages,
and
> therefore each of us has to solve the reservation question independently
in
> its own access network.
>
> For the current-status, using a single value means: when I send a
> current-status, I'm telling you about what *I did* in *my* access network
> for resource reservation. When I receive a current-status, I'm learning
> what *you did* in *your* access network for resource reservation.
>
> By the way, the example in section 9 seems to me a little bit strange. I
> agree that you can have several preconditions on the same media stream
> (even if for complexity reasons, I guess that most people will use only
one
> precondition), but can you still use at the same time the e2e approach
> *and* the segmented approach for the same media? Can you please explain
me
> how this can work ?

For example, I want to make sure that there are enough resources in the
access networks (where the bottlenecks typically are), and I would find
desirable, although not essential, to have resources in the backbone as
well.

Regards,

Gonzalo

> Best regards
> Juan Carlos

--
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027
USA                              [email-masked]

_______________________________________________
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

_______________________________________________
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: Fri, 15 Mar 2002 20:03:54 +0200

Hello,

> Is this right in your point of view ?

Yes.

> prefer by far the first approach.

You are not missunderstanding anything here. If I have e2e, I have Qos
in the access networks as well.

The only difference in the example were the strength tags. I want
mandatory QoS in the local and remote segments, but only optional e2e.
As a matter of fact, if the e2e strength tag is finally upgraded to
mandatory, subsequent offer/answers may get rid of the segmented lines,
since they would be covered by the e2e reservation.

Regards,

Gonzalo