Subject: RE: [Sip] Manyfolks: e2e meaning

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Fri, 15 Mar 2002 13:07:32 -0000

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

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 15 Mar 2002 10:58:45 -0600

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

Why not use the PSTN - it's all there :-)

Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Chen, Xin (Xin)
> Sent: Friday, March 15, 2002 7:08 AM
> To: Brian Williams; Chen, Xin (Xin)
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> 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.
> 
> 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
> 
> 
> Cc: [email-masked];
> [email-masked]; [email-masked]
> > > Agree! I think the e2e is really useless here. The
> impression I got
> > > from
> > the
> > > because getting a RSVP RESV message is the detection
> point that end
> > > to
> end
> > > 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.
> > [XC]I would never agree either, but I see no difference to
> use "e2e"
> > or "rsvp" here.
> > 
> > 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").
> > 
> > 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
> > 
> > > 
> > > 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
> > > 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
> > > 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
> > > 
> > > 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
> > 
> > 
> > 
> > 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
> 
> 
> Use [email-masked] for questions on current
> sip Use [email-masked] for new developments on the 
> application of sip
>