Subject: Re: [Sip] Manyfolks: e2e meaning

From: [email-masked]
Date: Fri, 15 Mar 2002 19:04:03 +0100

Gonzalo,

A small clarification: the definition of a protocol for resource
reservation and bearer setup, etc., etc. is clearly out of the scope of the
SIP WG, and I'm not asking for.
My question was only limited to indicate to the remote party, that I will
use the e2e feature, and so that I would like to use the protocol "x" to do
it. That's all.

Best regards
Juan Carlos

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

Sent by:  [email-masked]

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
cc:   "Chen, Xin (Xin)" <[email-masked]>, Brian Williams
      <[email-masked]>, [email-masked],
      [email-masked]
Subject:  Re: [Sip] Manyfolks: e2e meaning

Hello,

[email-masked] wrote:
>
> Hi Gonzalo,
>
> Thanks for your explanation. I agree with the trusting story, this is not
a
> problem for me.
>
> If I come back to my original question: does e2e mean RSVP in current
> manyfolks ?
> I understand from your explanation that the answer is NO. Am I right ?
>

You are right.

> In this case, how can I tell the other party what protocol I will use for
> e2e resource reservation ?
> I understand that your answer is: this is out of the scope of SIP WG. Am
I
> right ?

You are right.

> Here, I have still a problem; in corporate intranets we can expect that
> everybody is using the same protocol everywhere so maybe you don't need
to
> announce it, but in public networks, this can become quite different if
SIP
> is widely deployed.
> I'm worried on the fact that I'm able to negotiate the session
> characteristics, including media components, coding formats, etc, and
next
> I'm unable to setup resources because I don't know what protocol is used
by
> the remote party, so the only method is "trial and error". Am I right?

The negotiation mechanism is outside the scope of the SIP WG. You can
think that if another WG comes up with a protocol to negotiate QoS
parameters (including the protocol to use), a UAS will use that protocol
upon reception of an SDP including preconditions.

This is not that much different from the security stuff. MIKEY (which at
the end of the day is a different protocol than SIP) is used to
negotiate the security stuff... and MIKEY was not defined in the SIP WG.

Regards,

Gonzalo

>
> I have no problems to differentiate between the e2e approach and the
> segmented approach, providing that the definitions are clear. Please see
> also a related mail asking a question on the segmented approach.
>
> Best regards
> Juan Carlos
>
> Gonzalo Camarillo <[email-masked]> on 15/03/2002
> 18:07:23
>
> To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL
> cc:   "Chen, Xin (Xin)" <[email-masked]>, Brian Williams
>       <[email-masked]>, [email-masked],
>       [email-masked]
> Subject:  Re: [Sip] Manyfolks: e2e meaning
>
> Hello,
>
> we already had a discussion about this some time ago, but here we go
> again...
>
> First of all, the trusting thing that worries you (Chen) so much. As I
> already explained to you before, the whole SIP protocol, and in general
> every protocol, is based on trusting that the other end sends you
> messages that reflect real events. That is, if I am a UAS and I decide
> to send a 180 Ringing even though I am not alerting the user, it is not
> a failure in the protocol. It is a failure in the UAS implementation.
>
> The same way, if I place in my SDP an IP address that does not exist,
> you will be sending media to nowhere. Again, that does not mean that the
> offer/answer model is broken. It only means that my UAC does not work
> properly.
>
> And the same way, if an entity forwards RESV messages to me but does
> nothing regarding resource reservation, it is not a failure in RSVP nor
> in manyfolks... I hope you understand this time.
>
> About your statement saying that RSVP is the only e2e mechanism. What
> about ATM networks? A UAS may be able to obtain bidirectional resources
> for the call,  without using RSVP at all. What about my intranet, where
> I can run a proprietary e2e resource reservation protocol?
>
> As Brian stated in a previous note, the manyfolks draft provides a
> mechanism to express preconditions. It does not intend to provide a
> mechanism to negotiate QoS protocols. Such a mechanism/protocol is not
> to be defined by the SIP WG because the knowledge needed to define such
> a mechanism/protocol is not in the SIP WG. We do not deal with QoS
> reservation protocols and their negotiation. Other WGs might.
>
> I believe that you still do not understand the difference between
> segmented and e2e. Well, I guess what you want to know is the different
> between an e2e mechanism and a local reservation mechanism. I will give
> you an example. If I am a 3G terminal and I establish a PDP context,
> everything I know is that I have resources in my air interface. The fact
> that the PDP context has been successfully established does not tell me
> anything about the rest of the path towards the remote UA.
>
> However, if I use an e2e reservation protocol, when the reservation is
> established, I know that there are resources allocated thru all the
> path.
>
> I know, because you have said that a million times, that you are not
> going to use the e2e status type... good for you, don't use it. But
> there are other folks that intend to use it in their networks. Let them
> implement it if they want. Don't be selfish.
>
> I guess you are missunderstanding the status types because you believe
> that using the segmented status type implies that DiffServ is used in
> the network. This is not necessarily so. Many people claim that there is
> enough bandwithd in the backbone of the Internet. The bottelnecks are in
> the access network. People claiming that may want QoS in their accesses,
> but they are happy with the best effort service provided by the public
> Internet. In this case, the segmented status type is appropriate,
> whereas the e2e status type is not. Hope this helps...
>
> Best regards,
>
> Gonzalo
>
> [email-masked] wrote:
> >
> > Hi Xin and Brian,
> >
> > I agree with Xin: e2e means really end-user to end-user, and all the
path
> > along, otherwise this cannot work. In case of RSVP, this works because
> the
> > protocol itself provides some mechanisms to detect if the reservation
has
> > gone across a "non-RSVP cloud" (RFC2205, section 2.9)
> > For the time being RSVP is the only protocol in the IP world having
these
> > characteristics, but in the future other protocols could be created, as
> > e.g. the NSIS protocol.
> >
> > If any translation is being made somewhere in the network between RSVP
> and
> > "banana", this can become quite tricky, because it raises a lot of
> issues:
> > - it should be assumed that the interworking rules can be defined
without
> > loss of information
> > - none of the end-users know that there is some kind of translation
> > somewhere in the network
> > - if the translation occurs in the middle of the network (even if this
is
> > the worst solution), how the translation point can know that the
> > destination is "banana" aware and not RSVP aware ?
> > - very likely, this translation will be performed when entering or
> leaving
> > the QoS domain closest to the end-user, but here we are leaving the e2e
> > approach, and we are moving to the segmented approach.
> >
> > In summary, ideally
> > - when I launch a resource reservation, I use the protocol known by my
> > terminal
> > - if this is full end-to-end, I need some mechanism to detect that
there
> is
> > no "hole" in the path; this is foreseen in RSVP, any new "banana"
> protocol
> > should foresee it also.
> > - starting with the same protocol (no matter if it is RSVP or
"banana"),
> my
> > access network could translate it into another protocol; if any
> translation
> > occurs in the middle, I don't want to be aware of it, providing that I
> get
> > the service I'm requesting.
> > - even more, if my terminal is not using any protocol with the access
> > network (e.g., current ADSL) mon access network is maybe using some
> > protocol to go beyond the QoS domain border (RSVP, NSIS, etc.)
> >
> > Aren't we saying here, that finally, there is no so much difference
> between
> > the end-to-end approach and the segmented approach ?
> > I have problems to see how can this really work.
> >
> > Best regards
> > Juan Carlos
> >
> > "Chen, Xin (Xin)" <[email-masked]>@ietf.org on 15/03/2002 14:07:32
> >
> > Sent by:  [email-masked]
> >
> > To:   Brian Williams <[email-masked]>, "Chen, Xin
(Xin)"
> >        <[email-masked]>
> > cc:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL,
> [email-masked],
> >       [email-masked]
> > Subject:  RE: [Sip] Manyfolks: e2e meaning
> >
> > Hi Brian,
> >
> > It is very nice for the terminal to have that capabilities, nobody
stops
> > it.
> > But I don't see how this capabilities relying on  the "e2e" status
type?
> > You
> > can still apply such negotiation capabilities withou using the status
> type.
> > But if we have that "e2e" status type, then a call setup will fail
> because
> > the terminals can not find a common protocol to use, please note, the
> call
> > fails because there is no common RPOTOCOL not because there is no end
to
> > end
> > QOS! If you agree that manyfolks should not depend on any protocol,
then
> I
> > guess you also should agree that a call should not fail because there
is
> no
> > common protocol to  be used by UAC and UAS.
> >
> > On the contrast, if we don't have such a status type, then the call
setup
> > is
> > free from any actually QoS protocol. I guess all the terminals will
> always
> > try its best to get some QoS for its call. If the terminal supports a
QoS
> > reservation protocol like RSVP, it will always use it or try to
> negotionate
> > with another terminal to find a common protocol regardless there is a
> "e2e"
> > status type or not. If they find one, then great, they use it. If they
> > don't, then it is up to the terminals to decide whether they will
accept
> > the
> > local QoS or not rather than fail the call immeditetaly.
> >
> > Again, true end to end QoS means the resource has been reserved on all
> the
> > network routing devices alone the path to another end. It is something
> > lucky
> > to have but can not be assured unless you own all the devices.
> >
> > Going back to manyfolks itself, regarding the sentence below:
> >
> >           "B receives RESV messages conforming the reservation."
> >
> > Please answer my questions:
> >
> > Does getting a RSVP RESV message indicate the true end to end QoS is
> > achieved? If yes, how?
> > If no, why should we trust something that we know it is not always
true?
> >
> > Thanks
> >
> > Xin Chen
> >
> > Lucent Technologies
> > Tel: +44 1793 883137
> > Mobile: +44 7799 034668
> >
> > -----Original Message-----
> > From: Brian Williams [mailto:[email-masked]]
> > Sent: 15 March 2002 12:13
> > To: Chen, Xin (Xin)
> > Cc: [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: [Sip] Manyfolks: e2e meaning
> >
> > More comments inline.
> >
> > On Fri, 2002-03-15 at 22:45, Chen, Xin (Xin) wrote:
> > > Hi Brian,
> > >
> > > See inline please,
> > >
> > > Xin Chen
> > >
> > > Lucent Technologies
> > > Tel: +44 1793 883137
> > > Mobile: +44 7799 034668
> > >
> > >
> > > -----Original Message-----
> > > From: Brian Williams [mailto:[email-masked]]
> > > Sent: 15 March 2002 11:11
> > > To: Chen, Xin (Xin)
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]
> > > Subject: RE: [Sip] Manyfolks: e2e meaning
> > >
> > >
> > > Hi.
> > > On Fri, 2002-03-15 at 21:53, Chen, Xin (Xin) wrote:
> > > > Agree! I think the e2e is really useless here. The impression I got
> > from
> > > the
> > > > manyfolks draft is that the only way you can get end to end is
using
> > RSVP,
> > > > because getting a RSVP RESV message is the detection point that end
> to
> > end
> > > > is achieved. What happen that one terminal uses RSVP and another
> > terminal
> > > > uses a protocol called "banana" to do end to end? for sure, this
will
> > not
> > > > work in manyfolks. Therefore, the e2e here simply mandates that it
> > works
> > > > only if both terminals using the same QoS reservation protocol.
> > > > So my suggestion is to change the "e2e" parameter to "rsvp", then
all
> > the
> > > > SIP terminal will have to implement RSVP and we all get end to end
> QoS.
> > > I would not agree with chaging e2e to be RSVP. This would mean the
> > > manyfolks draft needs to be updated every time a new protocol is
> > > created. Manyfolks should not depend on the actual protocol in use.
> > >
> > > [XC]I would never agree either, but I see no difference to use "e2e"
or
> > > "rsvp" here.
> > >
> > > It would work if A uses RSVP and B uses "banana", as long as there is
> > > some point within the network where RSVP interworks with "banana". If
> > > there is no interworking, then of course the qos preconditions will
not
> > > be met because there will be no reply to the RSVP (or the "banana").
> > >
> > > [XC]Ok, Manyfolks will not depend on actually protcols, but depends
on
> > > interworking between different protocols! That is even worse, if we
> have
> > 100
> > > different QoS reservation protocols, then we have to have 100
> > interworking
> > > points in my network in order to get my SIP terminal work under
> > manyfolks.
> > > Simple question, before you start to devolopement the interwork
point,
> > how
> > > do you know which protocol you are going to interwork with? Today is
> > Banana,
> > > tomorrow maybe something else. So, let's give up the "e2e" idea today
> to
> > > save the cost to develop the interworking point in the future.
> > At present we have one e2e protocol (at least if you are considering IP
> > only, it is always possible that terminals may be using other
mechanisms
> > such as ATM too, which can be e2e depending on the network).
> >
> > As additional protocols are added, there becomes a need to negotiate
the
> > e2e protocol between terminals, and this can include negotiating using
> > capabilities provided by network equipment. Such negotiation would be
> > performed using a protocol aimed for this negotiation. This concept of
> > multiple building blocks which can be used together is a key strategy
> > for extending capabilities in IP networks, and I see no reason not to
> > apply it here too.
> >
> > >
> > > /brian
> > >
> > > >
> > > > By the way, manyfolks says:
> > > >
> > > >       "B receives RESV messages conforming the reservation."
> > > >
> > > > This is WRONG. Any router will route RESV packets even it is not
rsvp
> > > aware,
> > > > don't be cheated when getting the RESV message! Therefore, the
"e2e"
> > just
> > > > gives the terminal a chance to be cheated, a terminal can never be
> sure
> > > > whether the end to end QoS achieved unless you are in charge of the
> > RSVP
> > > > admission control for all the routers in the path between UAC and
> UAS,
> > in
> > > > other words, all the routers on the path are in your local network,
> in
> > > > another words "e2e" = "local". So, please not to introduce any
status
> > type
> > > > in manyfolks, they just can not achieve what they want to achieve.
> > > >
> > > >
> > > > Xin Chen
> > > >
> > > > Lucent Technologies
> > > > Tel: +44 1793 883137
> > > > Mobile: +44 7799 034668
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > [mailto:[email-masked]]
> > > > Sent: 15 March 2002 8:18
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: [Sip] Manyfolks: e2e meaning
> > > >
> > > >
> > > > Hello,
> > > >
> > > > In manyfolks-05, it is said that "status type: ...: The end-to-end
> > status
> > > > reflects the status of the end-to-end resource reservation"
> > > > In fact, end-to-end means that both end-users will exchange
> end-to-end
> > > some
> > > > messages using some protocol in order to reserve resources (this
> could
> > be
> > > > added for clarification, as it is never said in the draft).
> > > >
> > > > My question: Does "end-to-end" mean here RSVP ?
> > > > If the answer is yes, this is not a very future safe approach for
the
> > SDP
> > > > extensions, as other protocols could be defined also.
> > > > If the answer is no, how can I know which protocol will be used for
> > > > end-to-end resource reservation ?
> > > >
> > > > Best regards
> > > > Juan Carlos
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
> --
> 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]

--
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:15:01 +0200

Hi,

> use the e2e feature, and so that I would like to use the protocol "x" to do

Yes, I understand what you want. You want something like the offer
answer model. I support these codecs (reservation protocols), I support
these ones, so let's use one that we both support. It came out that the
offer/answer model was not that easy to be defined, and it may happen
that this is not that easy either. Therefore, a WG with the proper
competence will do it if necessary (the same way that MMUSIC defined the
offer/answer model).

But for the time being, it seems that many people find the lightweight
approach of the manyfolks draft as an advantage.

Regards,

Gonzalo