Subject: RE: [Sip] Manyfolks: e2e meaning

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Fri, 15 Mar 2002 19:23:44 -0000

Hi Gonzalo,

Please don't confuse the QoS with the QoS reservation protocol. QoS is the
result and the protocol is the method to get the result. But the method can
not always get the right result depending on different situation. 

In manyfolks, the end to end QoS is the result that the terminals want to
get, and the RSVP is the method to achieve the result. But the problem of
manyfolks I see is it believes that RSVP can always give end to end QoS. 

It is a very big possiblity that a RSVP RSEV messaage will travel a non-RSVP
capable clound (thanks for Brian giving me the reference RFC2205 2.9), when
the terminal gets that message, in manyfolks, the terminal or yourself
believe that end to end QoS is achieved, but is there really end to end QoS?
How does the terminal know that the non-RSVP clound has the enough resources
to support the real-time traffic? Of course, it doesn't know, they can only
trust the protocol, the message it gets. I am not worrying about the
trusting between the terminals, but what I am worrying is that we are still
missing the real thing we need--QoS, the result. When the terminals start to
exchange traffic, if the non-RSVP clound is very bandwidth limited, their
traffic still suffers. 

I am familiar with the 3GPP SIP architecture, our terminals don't use RSVP,
but this is not the reason I object this staturs type. This is not a 3GPP
specific issue, but also apply for IETF, becuase I believe that a lot of
other terminals don't use RSVP as well. I also believe there are lots of
people wanting to has end to end QoS, me too, but I have to say having the
stuts type will not make their life better but worse. You keep tell me
"there are other folks that intend to use it in their networks. Don't be
selfish.", where is the people, at least I have not seen one liking this
status type idea yet except you,  I would ask you not to be selfish, give
the RSVP none support terminals the chance to make a call.

Yes, maybe I still don't understand what does end to end QoS mean in your
definition. You also keep telling me "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.", I really have
difficulty to understand why I have to know by using a protocol like RSVP?
In your mind, there is only one type of end to end QoS which is achieved by
terminal using a QoS reservation protocol. If you and me are both on a 100M
ethernet but in different rooms, I don't know where you are and you don't
know where I am, we also have end to end QoS, this is another type of end to
end QoS which is not achieved by terminal itself but by network pre-given.
Yes, for this type of end to end, I don't know anything about your network,
but we enjoy the talk using SIP.

Unfortunetely, manyfolks only reflects the first type end to end QoS not the
second type. 

I also asked you before to give the definition or reference of "end to end
QoS" in manyfolks, I think this is a reasonable request. Since you are
teaching me what is end to end QoS, you must understand it very well from
some references, so please point it out to me and other readers please.

Thanks

Xin Chen

Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 15 March 2002 17:07
To: [email-masked]
Cc: Chen, Xin (Xin); Brian Williams; [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]

_______________________________________________
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 21:35:17 +0200

Hello,

> exchange traffic, if the non-RSVP clound is very bandwidth limited, their

If a router forwards a RESV message and his network does not have enough
resources, it is a problem in that router or in RSVP itself, not in
manyfolks.

Besides, how many times I have to explain you that RSVP is not the only
e2e QoS reservation protocol????? We have already mentioned ATM networks
and proprietary reservation protocols. Do I have to explain that
again????

> but this is not the reason I object this staturs type.

Again, RSVP != e2e

> This is not a 3GPP
> status type idea yet except you, 

This is a funny one. If you read the previous versions of manyfolks,
which was developed by the DCS guys in the first place, the only status
type was e2e. What I have added is the segmented status code that you
like so much... give me a break!!

> I would ask you not to be selfish, give

Again, RSVP != e2e

> difficulty to understand why I have to know by using a protocol like RSVP?

Again, RSVP != e2e. And again, the fact that a router forwards a RESV
message without having resources is a problem that belong to that router
and to RSVP, not to manyfolks, which is only an enabler.

> end QoS which is not achieved by terminal itself but by network pre-given.

Right. In this situation you do not need anything like manyfolks... why
should manyfolks cover an scenario where no extra signalling is needed?

> some references, so please point it out to me and other readers please.

Propose a definition and if it is sensible it will be added to the
draft.

Best regards,

Gonzalo