Subject: FW: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-00.txt

From: "Drake, John E" <[email-masked]>
Date: Fri, 9 Mar 2007 11:51:23 -0800

Francois,

I just read your I-D, below.  I was wondering whether the sender
notification method you propose should be applicable in the non-proxy
case as well?  

Thanks,

John 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Tsvwg] I-D ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-00.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group 
> Working Group of the IETF.
> 
> 	Title		: RSVP Extensions for Path-Triggered 
> RSVP Receiver Proxy
> 	Author(s)	: F. Le Faucheur, et al.
> 	Filename	: draft-ietf-tsvwg-rsvp-proxy-proto-00.txt
> 	Pages		: 19
> 	Date		: 2007-2-28
> 	
>    RSVP signaling can be used to make end-to-end resource reservations
>    in an IP network in order to guarantee the QoS required by certain
>    flows.  With conventional RSVP, both the data sender and 
> receiver of
>    a given flow take part in RSVP signaling.  Yet, there are many use
>    cases where resource reservation is required, but the receiver, the
>    sender, or both, is not RSVP-capable.  Where the receiver is not
>    RSVP-capable, an RSVP router may behave as an RSVP Receiver Proxy
>    thereby performing RSVP signaling on behalf of the receiver.  This
>    allows resource reservations to be established on the 
> segment of the
>    end-to-end path from the sender to the RSVP Receiver 
> Proxy.  However,
>    as discussed in the companion document presenting RSVP Proxy
>    Approaches, RSVP extensions are needed to facilitate 
> operations with
>    an RSVP Receiver Proxy whose signaling is triggered by receipt of
>    RSVP Path messages from the sender.  This document specifies these
>    extensions.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-prox
y-proto-00.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> "get draft-ietf-tsvwg-rsvp-proxy-proto-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-ietf-tsvwg-rsvp-proxy-proto-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 12 Mar 2007 15:03:59 +0100

Hello John,

In the non-proxy case, a regular RFC2205 RSVP router doing a CAC  
rejection sends a ResvErr towards the receiver, but does not normally  
issue any error message towards the sender. This is in line with the  
fundamental model of RSVP with receiver-driven operations and  
multicast support. I don't think we want to change this across-the- 
board for regular non-proxy operations. For example, when we have 10  
receivers and only the reservation of one receiver gets CAC-rejected  
while the reservations from each of the other 9 receivers gets  
accepted, there is no reason to send a PathErr to the sender.

Interestingly, RSVP-TE/RFC3029 did change the RFC2205 behavior in  
case of CAC rejection, and indeed specifies that the router doing CAC  
rejection sends a PathErr message to sender (with same Error-Code  
01="Admission Control Failure" that we are proposing to use in case  
of receiver proxy). RSVP-TE/RFC3209 could depart from RFC2205  
behavior because, in RSVP-TE, it can be assumed that (i) there is a  
single receiver and (ii) the reservation is actually sender-driven  
and not receiver-driven.

In a non-RSVP-TE environment, there may be a mixture of reservations  
terminating on a Receiver-Proxy and reservations terminating on real  
receivers, and there may be a mixture of unicast reservations and  
multicast reservations. For reservations terminating on real  
receivers, we don't want to change the RFC2205 behavior (particularly  
in case of multicast).
Since the RSVP router cannot distinguish between reservations that  
terminate on a proxy from reservations that terminate on a real  
receiver (unless we add something to that effect in signaling), we  
have to assume current RFC2205 behavior for all reservations.  
Besides, the RSVP midpoint routers in the network may be regular  
RFC2205 routers, which have not been upgraded for any specific proxy  
behavior and therefore will just behave as RFC2205.

So to try to give a short answer to your question: the proposed  
approach is to make sure that, like with RSVP-TE, the sender gets a  
PathErr with Error Code "CAC reject", but unlike RSVP-TE, to have  
this message generated by the Receiver Proxy instead of the router  
doing CAC reject because, unlike RSVP-TE, we cannot always assume
single-receiver & sender-driven-operations for all reservations.

I am realizing it may be worth adding these observations into rsvp- 
proxy-proto. Do you agree?

The proposed behavior has a number of merits: it uses same error  
message/error code as RSVP-TE, it does not affect behavior of RSVP  
routers (ie only affects Receiver Proxy, and optionally sender) and  
is a tiny change to RSVP protocol. So we see it as a good base approach.
However, it is not optimum. For example, a CAC rejection results in a  
ResvErr travelling from mid-point to Receiver-Proxy which then  
triggers a PathErr from Receiver-Proxy to sender, while you could get  
much faster notification directly from mid-point to sender. I am  
guessing this is the sort of sub-optimality you had in mind when  
asking about using the PathErr approach directly from midpoint. We  
plan to submit a proposal for an optional optimized approach allowing  
direct notification of the sender by the midpoint on CAC reject in  
case of receiver proxy. This approach is based on the Notify message  
(ie midpoint sends the ResvErr message directly to the sender inside  
the Notify message). The trick is that this would be done only for  
reservations which are controlled by an RSVP Receiver Proxy and for  
which the sender is interested in being made aware of CAC reject.  
This would allow (i) reservations terminating on real receivers to  
operate as per RFC2205 and (ii) reservations which terminate on  
Receiver Proxy and which have smart senders to get optimum CAC reject  
notification.

Perhaps we could discuss this approach in Prague.

Cheers

Francois

On 9 Mar 2007, at 20:51, Drake, John E wrote:

>> <ATT445931.TXT>
>> <draft-ietf-tsvwg-rsvp-proxy-proto-00.URL>

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 15 Mar 2007 12:30:11 -0700

Francois,

Comments inline.

Thanks,

John 

> From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
> Sent: Monday, March 12, 2007 7:04 AM
> To: Drake, John E
> Cc: Francois Le Faucheur IMAP; tsvwg tsvwg; Ashok (ashokn) Narayanan
> Subject: Re: [Tsvwg] I-D 
> ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-00.txt 
> 
> Hello John,
> 
> In the non-proxy case, a regular RFC2205 RSVP router doing a 
> CAC rejection sends a ResvErr towards the receiver, but does 
> not normally issue any error message towards the sender. This 
> is in line with the fundamental model of RSVP with 
> receiver-driven operations and multicast support. I don't 
> think we want to change this across-the- board for regular 
> non-proxy operations. For example, when we have 10 receivers 
> and only the reservation of one receiver gets CAC-rejected 
> while the reservations from each of the other 9 receivers 
> gets accepted, there is no reason to send a PathErr to the sender.

JD:  I wasn't proposing this in my e-mail

> 
> Interestingly, RSVP-TE/RFC3029 did change the RFC2205 
> behavior in case of CAC rejection, and indeed specifies that 
> the router doing CAC rejection sends a PathErr message to 
> sender (with same Error-Code 01="Admission Control Failure" 
> that we are proposing to use in case of receiver proxy). 
> RSVP-TE/RFC3209 could depart from RFC2205 behavior because, 
> in RSVP-TE, it can be assumed that (i) there is a single 
> receiver and (ii) the reservation is actually sender-driven 
> and not receiver-driven.

JD:  Is a PathErr also sent?

> 
> In a non-RSVP-TE environment, there may be a mixture of 
> reservations terminating on a Receiver-Proxy and reservations 
> terminating on real receivers, and there may be a mixture of 
> unicast reservations and multicast reservations. For 
> reservations terminating on real receivers, we don't want to 
> change the RFC2205 behavior (particularly in case of multicast).

JD:  Why not?

> Since the RSVP router cannot distinguish between reservations 
> that terminate on a proxy from reservations that terminate on 
> a real receiver (unless we add something to that effect in 
> signaling), we have to assume current RFC2205 behavior for 
> all reservations.

JD:  But you're not.  In your I-D, the proxy receivers have a different
behavior that appears to interoperate with the existing behavior
  
> RFC2205 routers, which have not been upgraded for any 
> specific proxy behavior and therefore will just behave as RFC2205.

JD:  Again, in my e-mail I wasn't proposing any intermediate node
behavior changes

> 
> So to try to give a short answer to your question: the 
> proposed approach is to make sure that, like with RSVP-TE, 
> the sender gets a PathErr with Error Code "CAC reject", but 
> unlike RSVP-TE, to have this message generated by the 
> Receiver Proxy instead of the router doing CAC reject 
> because, unlike RSVP-TE, we cannot always assume 

JD:  This is the the question I was asking in my e-mail, viz, why
wouldn't all uplevel receivers, proxy and non-proxy alike, do this?
There doesn't seem to be any reason to make a distinction between the
two.  The limiting case would be a node that was a proxy receiver for
some flows and a receiver for others - why should it have two separate
behaviors?

> 
> I am realizing it may be worth adding these observations into 
> rsvp- proxy-proto. Do you agree?

JD:  Sure

> 
> The proposed behavior has a number of merits: it uses same 
> error message/error code as RSVP-TE, it does not affect 
> behavior of RSVP routers (ie only affects Receiver Proxy, and 
> optionally sender) and is a tiny change to RSVP protocol. So 
> we see it as a good base approach.
> However, it is not optimum. For example, a CAC rejection 
> results in a ResvErr travelling from mid-point to 
> Receiver-Proxy which then triggers a PathErr from 
> Receiver-Proxy to sender, while you could get much faster 
> notification directly from mid-point to sender. I am guessing 
> this is the sort of sub-optimality you had in mind when 
> asking about using the PathErr approach directly from 
> midpoint. We plan to submit a proposal for an optional 
> optimized approach allowing direct notification of the sender 
> by the midpoint on CAC reject in case of receiver proxy.

JD:  Why doesn't this have the issues you detailed in your first
paragraph?
Also, how does an intermediate node know that it has proxy receivers,
and how would a mixed set of proxy and non-proxy receivers be handled?

> This 
> approach is based on the Notify message (ie midpoint sends 
> the ResvErr message directly to the sender inside the Notify 
> message).

JD:  Did you mean to say PathErr to the sender or ResvErr to the
receiver?  Otherwise, this sounds like a big change to the sender
behavior.  Why doesn't this have the issues you detailed in your first
paragraph, and how would an intermediate node know that a given sender
could deal with receipt of this?
 
> The trick is that this would be done only for 
> reservations which are controlled by an RSVP Receiver Proxy 
> and for which the sender is interested in being made aware of 
> CAC reject.

JD:  See above.  Why would a sender care whether a CAC reject was wrt a
proxy versus a non-proxy receiver?
  
> This would allow (i) reservations terminating on real 
> receivers to operate as per RFC2205 and (ii) reservations 
> which terminate on Receiver Proxy and which have smart 
> senders to get optimum CAC reject notification.

JD: To restate my original question, why are you making the distinction
between proxy versus non-proxy receiver behavior rather than between
receiver behavior as defined in RFC 2205 and receiver behavior (both
proxy and non-proxy) as defined in your I-D? 

> Perhaps we could discuss this approach in Prague.

JD:  Unfortunately I have had a change of plans 8-<

> >> Subject: [Tsvwg] I-D 
> ACTION:draft-ietf-tsvwg-rsvp-proxy-proto-00.txt
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts 
> >> directories.
> >> This draft is a work item of the Transport Area Working 
> Group Working 
> >> Group of the IETF.
> >>
> >>    flows.  With conventional RSVP, both the data sender 
> and receiver 
> >> of
> segment of 
> >> the
> >>    end-to-end path from the sender to the RSVP Receiver Proxy.  
> >> However,
> >>    Approaches, RSVP extensions are needed to facilitate operations 
> >> with
> message to 
> >> [email-masked] with the word unsubscribe in 
> the body 
> >> of the message.
> with the 
> >> username "anonymous" and a password of your e-mail address. After 
> >> logging in, type "cd internet-drafts" and then "get 
> >> draft-ietf-tsvwg-rsvp-proxy-proto-00.txt".
> >>
> >> Below is the data which will enable a MIME compliant mail reader 
> >> implementation to automatically retrieve the ASCII version of the 
> >> Internet-Draft.
> >>
> >> <ATT445931.TXT>

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 16 Mar 2007 09:24:55 +0100

Hello John,

Sorry for mis-understanding the question. So, if I got it right this  
time, the question is more :
"if the RSVP Receiver Proxy behavior is modified to send a PathErr on  
receipt of a ResvErr, then shouldn't a regular receiver also be  
modified to do the same?"
Right?

Here are some of the reasons I see for not changing the behavior of  
regular receivers:
	* when the receiver is RSVP capable, we can happily use the RFC2205  
receiver-driven model because the receiver can synchronise RSVP  
reservation state and application state (since it participates in  
both). The sender(s) needs not be aware of the RSVP reservation state  
- it doesn't care. We can then retain the benefits of receiver-driven  
operations which RFC2205 was seeking in the receiver-driven model ("  
In order to efficiently accommodate large groups, dynamic group  
membership, and heterogeneous receiver requirements, RSVP makes  
receivers responsible for requesting a specific QoS [RSVP93]. ").  
Even for the most simple single_render/single_receiver reservations,  
we save signaling and per-hop RSVP processing by not sending any  
error message to sender in case of CAC reject.
	* the motivation for adding sender error notification in case of  
receiver proxy is because the receiver can no longer synchronize RSVP  
reservation with application state, while the sender can. This  
motivation does not apply in case of regular receiver.
	* there is a lot of code and deployed systems happily working with  
current RFC2205 model in the absence of proxy today. We wouldn't want  
to change current behavior for those unless there is a very strong  
motivation.

Again, the current proposal is a very simple way to provide the  
necessary sender notification for reservations which are handled by a  
receiver proxy (and it reuses the approach already used in RSVP-TE  
for the same requirement).

Now, if we step back and try define what would be an ideal solution,  
I'd say it should:
	* ensure that the notification is sent directly to the sender by the  
failure point (instead of sent by the receiver proxy), which would  
provide faster sender notification and reduce the RSVP signaling  
burden on the network
	* ensure that this sort of notification is only sent to senders  
which are capable&willing to do something with it (i.e. synchronize  
with application signaling) and only sent in case the receiver is not  
capable&willing to do the synchronization (e.g. receiver proxy).
The proposal I alluded to earlier is aiming for this. We need to  
document it. Pity we won't get the chance to discuss it in Prague.

This sort of ideal solution is a good objective as a 2nd step, but I  
feel we should start with the very simple Receiver Proxy behavior  
currently proposed as 1st step.

Does it make sense?

Francois

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 16 Mar 2007 08:00:50 -0700

Francois,

I think you should contents of your e-mail, below, in your I-D.  It
provides a great context and motivation for your proposed change.

Thanks,

John 

> Sent: Friday, March 16, 2007 1:25 AM
> To: Drake, John E
> Sorry for mis-understanding the question. So, if I got it 
> right this time, the question is more :
> "if the RSVP Receiver Proxy behavior is modified to send a 
> PathErr on receipt of a ResvErr, then shouldn't a regular 
> receiver also be modified to do the same?"
> Right?
> 
> Here are some of the reasons I see for not changing the 
> behavior of regular receivers:
> 	* when the receiver is RSVP capable, we can happily use 
> the RFC2205 receiver-driven model because the receiver can 
> synchronise RSVP reservation state and application state 
> (since it participates in both). The sender(s) needs not be 
> aware of the RSVP reservation state
> - it doesn't care. We can then retain the benefits of 
> receiver-driven operations which RFC2205 was seeking in the 
> receiver-driven model ("  
> In order to efficiently accommodate large groups, dynamic 
> group membership, and heterogeneous receiver requirements, 
> RSVP makes receivers responsible for requesting a specific 
> QoS [RSVP93]. ").  
> Even for the most simple single_render/single_receiver 
> reservations, we save signaling and per-hop RSVP processing 
> by not sending any error message to sender in case of CAC reject.
> 	* the motivation for adding sender error notification 
> in case of receiver proxy is because the receiver can no 
> longer synchronize RSVP reservation with application state, 
> while the sender can. This motivation does not apply in case 
> of regular receiver.
> 	* there is a lot of code and deployed systems happily 
> working with current RFC2205 model in the absence of proxy 
> today. We wouldn't want to change current behavior for those 
> unless there is a very strong motivation.
> 
> Again, the current proposal is a very simple way to provide 
> the necessary sender notification for reservations which are 
> handled by a receiver proxy (and it reuses the approach 
> already used in RSVP-TE for the same requirement).
> 
> Now, if we step back and try define what would be an ideal 
> solution, I'd say it should:
> 	* ensure that the notification is sent directly to the 
> sender by the failure point (instead of sent by the receiver 
> proxy), which would provide faster sender notification and 
> reduce the RSVP signaling burden on the network
> 	* ensure that this sort of notification is only sent to 
> senders which are capable&willing to do something with it 
> (i.e. synchronize with application signaling) and only sent 
> in case the receiver is not capable&willing to do the 
> synchronization (e.g. receiver proxy).
> The proposal I alluded to earlier is aiming for this. We need 
> to document it. Pity we won't get the chance to discuss it in Prague.
> 
> This sort of ideal solution is a good objective as a 2nd 
> step, but I feel we should start with the very simple 
> Receiver Proxy behavior currently proposed as 1st step.
> 
> Does it make sense?
> 
> Francois
> 
> 
> >> 01="Admission Control Failure"
> >> RSVP-TE/RFC3209 could depart from RFC2205 behavior because, in 
> >> RSVP-TE, it can be assumed that (i) there is a single receiver and 
> >> (ii) the reservation is actually sender-driven and not 
> >> receiver-driven.
> >
> reservations 
> > JD:  But you're not.  In your I-D, the proxy receivers have a 
> > different behavior that appears to interoperate with the existing 
> > behavior
> >
> specific proxy 
> results in a 
> >> case of receiver proxy.
> >> approach is based on the Notify message (ie midpoint sends the 
> >> ResvErr message directly to the sender inside the Notify message).
> >
> >> The trick is that this would be done only for reservations 
> which are 
> >> controlled by an RSVP Receiver Proxy and for which the sender is 
> >> interested in being made aware of CAC reject.
> >
> > JD:  See above.  Why would a sender care whether a CAC 
> reject was wrt 
> > a proxy versus a non-proxy receiver?
> >
> > JD: To restate my original question, why are you making the 
> > distinction between proxy versus non-proxy receiver behavior rather 
> > than between receiver behavior as defined in RFC 2205 and receiver 
> > behavior (both proxy and non-proxy) as defined in your I-D?
> >
> >>
> >>>>    cases where resource reservation is required, but the 
> receiver, 
> >>>> the
> operations