Subject: RE: [Sip] Manyfolks: e2e meaning

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Fri, 15 Mar 2002 11:45:26 -0000

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.

/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: Brian Williams <[email-masked]>
Date: 15 Mar 2002 23:12:37 +1100

More comments inline.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 15 Mar 2002 19:12:25 +0200

Hi,

> This concept of

Exactly! This is the biggest difference between net and bell heads!
Right, Henry? ;o)

Regards,

Gonzalo