Subject: [Tsvwg] AD comments on RSVP proxy approaches and proto

From: Magnus Westerlund <[email-masked]>
Date: Tue, 01 Jul 2008 18:10:54 +0200

Hi,

I have reviewed draft-ietf-tsvwg-rsvp-proxy-proto-06 and
draft-ietf-tsvwg-rsvp-proxy-approaches- 04 and have some comments.

Lets start with approaches:

A1. I am missing discussion for the different approaches on what the
downsides of them are. It is clear that some has some significant
potential problems, like the inspection based one.

A2. I am also missing the discussion on how one can determine that there
are RSVP proxies present, and secondly how one ensure that it is the
right one that is used. For example in receiver proxies, how does it
know that it should respond to the PATH message? How can it know if
there are any other proxy closer to the receiver or if that receiver is
in fact RSVP capable. This needs to be discussed as if affects
applicability significantly.

A3. Section 4.3: I think there is a significant risk that this type of
proxy can interact badly with the application, especially if one some
senders are starting to use RSVP themselves. Then multiple reservations
can start happen. Please discuss this issue where applicable.

A4. Section 4.4: How can a RSVP proxy separate a STUN message that is
part of an ICE exchange rather than going to a stand-alone STUN server?
Making reservations towards a STUN server that is only used to learn
what reflexive address the client has is quite wasteful.

A5. Section 4.4: I feel quite uncomfortable by the discussion about
bandwidth in STUN for the purpose of having RSVP proxies assign
bandwidth. Is this really an architecture we want? Things that magically
happens.

A6. Section 4.2: I think this is a reasonable approach. However the
dependency on symmetry seems quite problematic. Have anyone considered
what extensions are necessary to indicate if this is at all desired and
if then what parameters in the reservation that are desired.

A7. The document isn't particular clear on what approaches are usable
out of the box today with the current specs. I get the impression that
several are possible. Should this be made clearer.

Proto:

P1. The reference to draft-ietf-tsvwg-rsvp-approaches needs to be an
informational one. In its usage in the document it is clear that is for
understanding, but not necessary for implementation. If not we have a
downref issue.

 From my perspective I think approaches needs quite some work to better
explain RSVP proxies place in the word and its implication and
applicability. However the extensions for the specific case looks to be
in quite good shape.

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 1 Jul 2008 20:36:33 +0200

Hello Magnus,

Thanks for the thorough review. Thoughts/proposals embedded below:

On 1 Jul 2008, at 18:10, Magnus Westerlund wrote:

> downsides of them are.

Assuming you are also missing the upsides of them [ '^) ], we could  
indeed include a brief pros/cons discussion under each approach.

Just as an example, for 4.1 we could add a paragraph capturing key  
points like:
Cons:
	* needs extensions beyond existing RSVP
	* by definition, only supports Receiver Proxy side
Pros:
	* only needs small extensions beyond existing RSVP [proxy-proto]
	* does not need involvement of components outside of RSVP routers  
(ie no involvement of application layer component, no involvement of  
any policy server etc.)
	* does not depend on using any other protocol (like STUN)
	* does not need any datapath capabilities (like Inspection)

Would that sort of text address the point appropriately (if done for  
4.1 to 4.7)?

> It is clear that some has some significant

The document is very explicit that the recommended model remains RSVP  
end-to-end and RSVP Proxy is only to be used in some environments  
where end to end RSVP is not possible:
" It is important to keep in mind that the strongly recommended RSVP
    deployment model remains end to end as assumed in [RFC2205] with  
RSVP
    support on the sender and the receiver.
...
   The present document should not be seen as an
    encouragement to depart from the end to end RSVP model.  Its purpose
    is only to allow RSVP deployment in special environments where RSVP
    just cannot be used on some senders and/or some receivers for  
reasons
    specific to the environment.
"

As a result, the objective is not to devise RSVP Proxy approaches  
that will work in all situations and don't require any configuration.
So to your question above, the RSVP Proxy does not dynamically  
determines that it is the last receiver proxy for a flow. It just has  
to be told. This generally is achieved via some form of  
configuration, either on the RSVP node itself , or some the entity  
that triggers the RSVP node (e.g App entity/Policy Server).

This is already somewhat covered eg in section 4.1 we have:
"With the Path-Triggered RSVP Receiver Proxy approach, the RSVP router
    may be configured to use receipt of a regular RSVP Path message as
    the trigger for RSVP Receiver Proxy behavior.
"

But we can be bring up this high level point that some config is  
assumed/required (and give examples with a few approaches) and draw  
attention to corresponding deployment implications. We can do this in  
a new section 4.9. (this approach is kind of similar to what we did  
in section 4.8 where we discussed a Proxy deployment issue that is  
generic across all approaches).

> can start happen. Please discuss this issue where applicable.

Again, in general Proxy only works if there is some config indicating  
where top use (or not do RSVP proxy).
But this specific approach does suffer from limited feedback  
mechanism to application. We can point that out in the pros&cons  
discussion that will be added into that section.

> what reflexive address the client has is quite wasteful.

I was assuming that it is possible to distinguish from the two types  
of STUN messages (ie bw the one to the STUN server and the one used  
between endpoints for connectivity checks). Dan will probably be able  
to provide us with specifics on that one.
> bandwidth. Is this really an architecture we want? Things that  

In situations where RSVP cannot be deployed end-to-end and RSVP  
proxies are to be used and if STUN is there to do other magic things  
(like dynamically discover the best addresses to use for  
communications through NAT) I don't see why it would be bad that STUN  
also does good things to facilitate QoS reservations. But that may be  
beside the point of this document. It is an informational document  
describing the various possible approaches and (now) presenting  
associated pros&cons. If you see concerns/shortcomings we can bring  
them up in the pros&cons discussion for that approach.

> dependency on symmetry seems quite problematic.

This does limits applicability. But there are still quite a few  
scenarios where it is predictably applicable (eg single WAN router  
out of a site, single Access Router at the edge of a network).  
Anyway, the limitation is discussed and will be listed in the pros&cons.

> Have anyone considered

I am not sure I got the question.
The approach of 4.2 does not require any RSVP extensions (as stated  
in I-D). Now if you are talking about RSVP extensions that allow to  
deal with asymmetric paths (and asymmetric bandwidth requirements),  
then this was covered by Jukka in his I-D.manner-tsvwg-rsvp-proxy- 
sig. But this falls under the "RSVP-Signaling-Triggered Proxy"  
approach as described in section 4.7.
Certainly ability to deal with asymmetric paths/asymmetric bw would  
be fair points to list under the "pros" of pros&cons of section 4.7.

> several are possible. Should this be made clearer.

The document attempted to discuss pretty exhaustively where protocol  
extensions were/were not required. Here is what we currently have:

4.1:
  [I-D.ietf-tsvwg-rsvp-proxy-proto] specifies RSVP extensions allowing
    such sender notification in case of reservation failure in the
    presence of a Path-Triggered RSVP Receiver Proxy.

4.2:
We observe that this approach does not require any extensions to the
    existing RSVP protocol.

4.3:
Note also that this approach does not
    require any change to the RSVP protocol.

4.4:
  The STUN message could also include (yet to be specified) STUN  
attributes ...
The corresponding extensions to ICE and STUN for such a STUN-
    triggered RSVP Proxy approach are beyond the scope of this  
document....

4.5:
  This RSVP Proxy approach does not require any extension to the RSVP
    protocol.  However, it relies on an RSVP Proxy control interface
    allowing control of the RSVP Proxy by an application signaling
    entity.

4.6:
This RSVP Proxy approach does not require any extension to the RSVP
    protocol.  However, as with the Application_Entity-Controlled Proxy
    approach presented in Figure 9, this approach relies on an RSVP  
Proxy
    control interface allowing control of the RSVP Proxy (by the Policy
    Server in this case).

4.7:
Such an RSVP-Signaling-Triggered Proxy approach would require RSVP
    signaling extensions (that are outside the scope of the present
    document)

The only thing I can think of adding would be an explicit statement  
in section 4.4 that no RSVP extensions are required.
What other clarification do you see needed?

> informational one.

agreed. This has been fixed and new version posted.

> In its usage in the document it is clear that is for
> applicability.

Hopefully the proposals above can form a good base. I'll be looking  
forward to your feedback and will edit accordingly.

> However the extensions for the specific case looks to be
> in quite good shape.

Great.

Francois.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 1 Jul 2008 16:32:00 -0700

> between endpoints for connectivity checks). Dan will probably 
> be able to provide us with specifics on that one.

We have tossed around several ideas, and each is appealing in different
network architectures:

1. PRIORITY, USE-CANDIDATE, ICE-CONTROLLED and ICE-CONTROLLING
   only appear in ICE connectivity checks, and are a reliable way
   of differentiating STUN binding discovery from ICE
   connectivity checks.
2. (As Francois mentioned) the RSVP proxy is configured to know it 
   is supposed to proxy certain traffic, and would not be configured 
   to proxy traffic to/from a STUN server (by the STUN server's IP 
   address and/or UDP port).
3. Wait for a STUN message with USE-CANDIDATE to indicate the selected
   path (which is useful to avoid double-booking, especially when ICE
   is being used for v4/v6 path selection)
4. Use the DSCP value to differentiate between STUN connectivity
   checks (which would match the RTP flow's DSCP value) versus STUN
   binding discovery messages (which would not match the RTP flow's
   DSCP value).

I expect a reasonable implementation would use 4 to decide if the UDP packet
even warrants peeking inside of, then 1 and 2 determine if RSVP proxying
should be performed.

If we do decide to add a BANDWIDTH attribute to provide additional information
to the RSVP proxy function (so that the RSVP proxy function does not have to
guess the bandwidth of the flow), the existence of that attribute would also
indicate an ICE connectivity check (and thus be an additional indicator along
with #1, above).

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 02 Jul 2008 11:03:01 +0200

Francois Le Faucheur IMAP skrev:
> (ie no involvement of application layer component, no involvement of any 
> policy server etc.)
> Would that sort of text address the point appropriately (if done for 4.1 
> to 4.7)?
> 

I was missing the discussion of some serious issues, like how unreliable 
any data inspection method is. How prone to make wrong assumptions about 
the traffic it is seeing.

I thought there where some more fundamental downsides also to others 
that should be discussed.

Frankly, I don't know if a Pro/Con list is to detailed.

> end-to-end and RSVP Proxy is only to be used in some environments where 
> end to end RSVP is not possible:
>    deployment model remains end to end as assumed in [RFC2205] with RSVP
>    just cannot be used on some senders and/or some receivers for reasons
> As a result, the objective is not to devise RSVP Proxy approaches that 
> will work in all situations and don't require any configuration.
> determines that it is the last receiver proxy for a flow. It just has to 
> be told. This generally is achieved via some form of configuration, 
> either on the RSVP node itself , or some the entity that triggers the 
> RSVP node (e.g App entity/Policy Server).
> 
> attention to corresponding deployment implications. We can do this in a 
> new section 4.9. (this approach is kind of similar to what we did in 
> section 4.8 where we discussed a Proxy deployment issue that is generic 
> across all approaches).

I think you need to move this before the different approaches, so that 
one have it in ones mind when one comes to the actual approaches. It is 
in fact a scoping and applicability thing of this document that needs to 
be made clear.

> But this specific approach does suffer from limited feedback mechanism 
> to application. We can point that out in the pros&cons discussion that 
> will be added into that section.

Ok

> I was assuming that it is possible to distinguish from the two types of 
> STUN messages (ie bw the one to the STUN server and the one used between 
> endpoints for connectivity checks). Dan will probably be able to provide 
> us with specifics on that one.

Okay, once more some discussion about the potential issue are at least 
needed.

> In situations where RSVP cannot be deployed end-to-end and RSVP proxies 
> are to be used and if STUN is there to do other magic things (like 
> dynamically discover the best addresses to use for communications 
> through NAT) I don't see why it would be bad that STUN also does good 
> things to facilitate QoS reservations. But that may be beside the point 
> of this document. It is an informational document describing the various 
> possible approaches and (now) presenting associated pros&cons. If you 
> see concerns/shortcomings we can bring them up in the pros&cons 
> discussion for that approach.

To me it usage of STUN has the following issues:

- Additional dependency on STUN and its security model beyond what was 
intended with its basic usage
- potential for spurious reservations where no real user data will flow
- No real information about what flow is going to use the flow 
identifiers checked by STUN.

In short it is using a protocol for something it isn't intended to. 
Several of the other approaches have very similar issues.

> scenarios where it is predictably applicable (eg single WAN router out 
> of a site, single Access Router at the edge of a network). Anyway, the 
> limitation is discussed and will be listed in the pros&cons.
> 
>> Have anyone considered
> The approach of 4.2 does not require any RSVP extensions (as stated in 
> I-D). Now if you are talking about RSVP extensions that allow to deal 
> with asymmetric paths (and asymmetric bandwidth requirements), then this 
> was covered by Jukka in his I-D.manner-tsvwg-rsvp-proxy-sig. But this 
> falls under the "RSVP-Signaling-Triggered Proxy" approach as described 
> in section 4.7.
> Certainly ability to deal with asymmetric paths/asymmetric bw would be 
> fair points to list under the "pros" of pros&cons of section 4.7.

Okay, probably sloppy reading by me. The above clarified things for me. 
Just make sure the document is clear on this.

>    triggered RSVP Proxy approach are beyond the scope of this document....
> 
> 4.5:
>    approach presented in Figure 9, this approach relies on an RSVP Proxy
> The only thing I can think of adding would be an explicit statement in 
> section 4.4 that no RSVP extensions are required.

No, not really. I should have been less lazy and gone back to verify 
this question that arouse during the writing of the comments instead of 
relying on my clearly imperfect memory of the document.

> forward to your feedback and will edit accordingly.

I hope you will be able to start doing the edits now. If there are more 
questions don't hesitate to ask them.

Cheers

Magnus Westerlund

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 2 Jul 2008 12:36:32 +0200

hi

two additional comments on this doc:

  "Since the data sender or receiver may be unaware of RSVP, there are
   two types of RSVP Proxies.  When the sender is not using RSVP, an
   entity in the network must operate on behalf of the data sender, and
   in particular, generate RSVP Path messages, and eventually receive,
   process and sink Resv messages.  We refer to this entity as the RSVP
   Sender Proxy.  When the receiver is not using RSVP, an entity in the
   network must receive Path messages sent by a data sender (or by an
   RSVP Sender Proxy), sink those, and return Resv messages on behalf of
   the data receiver(s).  We refer to this entity as the RSVP Receiver
   Proxy."

why does the protocol arch. imposes the proxy to be "in the network".
this would deserve clarification.

  " Its purpose is only to allow RSVP deployment in special environments 
  where RSVP just cannot be used on some senders and/or some receivers 
  for reasons specific to the environment."

is this preventing end-to-end RSVP to operate ? i mean there is lots
of text describing how good the end-to-end model is compared to this 
model but there is no description about hybrid environments. 

in brief, is a proxy able to behave as a standard RSVP router in case 
sender/receiver on path are RSVP capable. you can see the resulting 
are these proxies not preventing ultimately the end-to-end deployment 
of RSVP ?

thanks,
-d. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Magnus Westerlund
> Sent: Tuesday, July 01, 2008 6:11 PM
> To: [email-masked]; 
> [email-masked]; tsvwg
> Subject: [Tsvwg] AD comments on RSVP proxy approaches and proto
> 
> Hi,
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 2 Jul 2008 23:27:25 +0300 (EEST)

Hi Dimitri and Magnus,

Just a note on the asymmetric and hybrid models. I've played with this 
"proxy RSVP" concept since about 2000, and had so-called "Localized 
RSVP" drafts floating around the IETF repositories since 2002. The latest 
once (about 2 years old) is still available2:

http://tools.ietf.org/html/draft-manner-tsvwg-rsvp-proxy-sig-00

In that scheme, I used one bit in the Session Object to identify when a 
message is meant to be proxied, and when not, i.e., when the bit is not 
set, the signaling should go e2e, and when it is set, a proxy on the path 
terminates the signaling. This same concept has been adopted by NSIS 
protocols. Naturally this does not support layers of proxies, one or none.

The RSVP proxy draft authors decided not to pursue this proxy/e2e 
separation at this stage, but rather go for an overall problem statement 
and simpler initial spec. If the RSVP protocol should run in a hybrid 
environment, we can surely think about some larger technical enhancements 
to the protocols, such as, this 1 bit extension.

About the asymmetric routing, this is a challenge that has also been noted 
in NSIS, i.e., if your outbound and inbound routes differ, then you are 
more or less done. Say you want to signal for an incoming flow, and you 
set up reservations on a certain path, but then the flow actually arrives 
through another path. There are various hacks you could envisage, but I 
don't recall any clear solution to this challenge.

Thanks for the good feedback,
Jukka