Subject: [Tsvwg] Review of RSVP Proxy Approaches

From: "James M. Polk" <[email-masked]>
Date: Mon, 24 Mar 2008 15:02:54 -0500

TSVWG

This is my WG chair review of
http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-proxy-approaches/

Overall, this is an well written document.  I have some comments 
regarding some portions of the text in -03, as follows:

In the Abstract, it says " With conventional RSVP..."  Shouldn't this 
say "RSVPv1" or "RSVP version 1"?

   "This
   document presents RSVP Proxy behaviors allowing RSVP routers to
   perform RSVP signaling on behalf of a receiver or a sender that is
   not RSVP-capable."

Switch "perform" with "...initiate or terminate..."

   This allows resource reservations to be
   established on critical parts of the end-to-end path.

Switch " the end-to-end path" with "... the end-to-edge, edge-to-edge 
or edge-to-end paths."

In the Intro section

I suggest adding the following to the end of the 1st paragraph of the 
Intro "...for example, flows such as end-to-edge, edge-to-edge and 
edge-to-end paths."

In the second paragraph, there's this

   Since the data sender or receiver may be unaware of RSVP, there are
   two scenarios.

s/or/"and/or" and
s/two/three

at the end of the second paragraph, this is where I would add a third 
example, which is Proxy-to-Proxy (which is what CUCM would does today).

This third example is also what you highlight in Figure 7 on page 14, 
so this comment applies - and probably ought to be mentioned here.

At the end of the 5th paragraph, which starts with " The IETF Next 
Steps in Signaling (NSIS)...", there ought to be a 2205 reference to 
bring this point home.

Comment on transition between sections 2 and 2.1

I don't know if it's clear that existing [2205-based] RSVP signaling 
works with Proxies as described so far. This should be stated firmly 
somewhere in Section 2., and before Section 2.1 IMO.  In other words, 
this document is not changing existing RSVP signaling, just what can 
start/initiate and end/terminate RSVP signaling.

In section 2.1, in the paragraph that starts " In order for 
reservations..." there is a "should" that's lowercase. Is this 2119 
SHOULD? If not, the word needs to be different. If it is 2119 
language, it needs to capitalized.

Section 2.2, second paragraph says "...somehow know..."

this is question answered?

Or is this out of scope for this doc?

Can it be a case that the sender proxy is configured to initiate a 
path every time one isn't detected (under certain conditions)?

In other words, so far, this doc does a good job explaining what the 
proxy is, but doesn't do anything for how the proxy knows when to do 
anything. Perhaps a few words on this is needed.

If this is to be explained later, a hint that this is coming would be 
good (as the objective for this section perhaps).

Nit in section 3, with the paragraph starting with "Note..." this 
should be indented 3 additional spaces to set it further apart, the 
way I read it.

In the last paragraph of section 3, there are application examples 
(SIP and RTSP). Firstly, IMO, add SDP (because that is the only 
protocol that carries the RFC3312 specific signaling wrt wanting a 
reservation and what BW is desired).

Next, each of these three need informational references (SIP-3261, 
SDP-4566, RTSP-2326) in this doc.

I'm currently confused by the inconsistent signaling paths (no pun 
intended) in section 4.2 (with other sections in Approaches and ones 
in the RSVP Proxy doc). Currently there is this signaling

    |----|        ***         ***        |----------|         |----|
    | R |---------*r*----------*r*---------| RSVP    |----------| S |
    |----|        ***         ***        | Sender  |         |----|
                                            | Proxy   |
                                            |----------|

         ---Path---> ----Path----> ---Path---->

         <--Path---> <---Path----- <--Path----

         ---RESV---> ----RESV----> ---RESV---->

        <================RSVP==================

since you have PATHs going in both directions, why aren't there RESVs 
going in both directions? If the first PATH is only to trigger the 
PATH in the reverse direction, won't the R (endpoint) believe it is 
done sending PATH messages and not send another one (to the right in 
this diagram) to get a two-way reservation?

Further, if reservations are to only be in one direction, how does 
the RSVP-Capable Receiver know that the Non-RSVP-Capable sender's 
flow will go *to* this proxy in the first place? This is a challenge 
that should be mentioned, since the receiver (on the left of the 
page) has no control over the sender on the right of the page, no 
does the receiver have knowledge of the entire forwarding table 
getting to the proxy router, right?

The paragraph after Figure 5., mentions " This is illustrated in 
Figure 6." I'd like to understand more about Figure 5's use-case, and 
why this needs to be different from Figure 6's; especially given the 
comments above. As I look at Figure 6, it appears to be a normal 
two-way reservation, yet this is mentioned to be a likely scenario 
based on Figure 5, which has an unusual signaling behavior (that I've 
mentioned). I'd like a clearer explanation of how the signaling in 
Figure 5 works and turns into the signaling of Figure 6. I.e., 
explain how the RSVP-Proxy unaware endpoint knows it has to send two 
PATHs, each at different times in the signaling, to get one two-way 
reservation?

Section 4.3, the second paragraph below Figure 7 has this
"...so that the application takes appropriate action (for example 
terminate the corresponding session..."

At what point does the application know to terminate anything?

SIP, for example, sure wouldn't - because it has zero feedback itself 
in this scenario. I think something like RTCP (RFC 3550) needs to be 
mentioned as the feedback mechanism for RTP based streams.

Section 4.3, in the next sentence has

   "To
   mitigate this problem, the inspection-triggered RSVP Proxy may mark
   differently the DSCP of flows for which an RSVP reservation has been
   successfully proxied from the flows for which a reservation is not
   in place.

How is this accomplished?

If mentioned as a solution, you should explain an example of how this 
can be accomplished.

Right now, my DSCP attribute in SDP (in MMUSIC)
http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-attribute-02.txt
*can* (but doesn't have to) be a mentioned (informational) reference. 
This probably shouldn't be mentioned, since this effort isn't going 
well in MMUSIC, lacking a viable use-case to the WG's satisfaction. 
That said, without this SDP capability, how is Approaches text 
supported by an existing or future mechanism?

RFC4542 also mentions this scenario (a reservation goes away, but the 
application (by configuration) wants to keep it up (perhaps using a 
scavenger class codepoint) instead of tearing the call or flow down. 
This might be worth mentioning here.

Section 4.3, in the next sentence

   In some situations, the Inspection-Triggered Proxy might be
   able to modify the "packets of interest" (e.g. application signaling
   messages) to convey some hint to applications that the corresponding
   flows cannot be guaranteed by RSVP reservations.

I would also mention it falls on the proxies to burden the load of 
attempting to reestablish a new reservation if the flow isn't to be torn down.

In section 4.4, has this below Figure 8

   For unicast flows, [I-D.ietf-mmusic-ice] is an already widely-adopted
   emerging standard for NAT traversal.

An internet draft is a "widely adopted emerging standard"?

Hmmmm.....

I think it is a widely accepted direction many are moving in, but it 
isn't a standard yet, so this doc shouldn't say that it is.

In section 4.4, in the same paragraph below Figure 8

   "By
   including new STUN attributes in those connectivity check messages,
   an RSVP Proxy agent could perform its functions more effectively."

More effectively than what, exactly?

I'd say it is more efficient than packet snooping of Section 4.3

If this is what you mean here, that needs to be said here (to scope 
what you are saying)

Also in section 4.4, in the same paragraph below Figure 8

   "This provides very RSVP-
   like call admission control and signaling to the endpoints, without
   implementing RSVP on the endpoints..."

This seems to be advocating never coding RSVP on endpoints. Is this 
what is meant here?

I hope not. I would think you want to say this is an efficient 
trigger for RSVP Proxies, mitigating less efficient means of trigger 
RSVP Proxies - until RSVP is coded in an (or all) endpoint(s).

Also in section 4.4, in the next paragraph (below Figure 8)

   "For multicast flows (or certain kinds of unicast flows that don't or
   can't use ICE), a STUN Indication message
   [I-D.ietf-behave-rfc3489bis] could indicate the flow's bandwidth..."

I'd be careful with "could" when referring to IDs that don't have the 
text in them to support what the could in this ID are trying to mean.

In section 4.5, in the paragraph below Figure 9

   "As an example, the Application_Entity-Controlled Proxy may be used in
   the context of Session Border Controllers (SBCs) (see
   [I-D.ietf-sipping-sbc-funcs] for description of SBCs) to establish
   RSVP reservations for multimedia sessions."

After the "of", add "SIP Servers" [RFC3261] first, then you can 
mention SBCs - but since SBCs are usually considered border elements, 
there are few of these facing an endpoint within a administrative 
domain (thus perhaps making readers wonder about the applicability)

In section 4.5, in the next paragraph below Figure 9, there is the 
sentence starting with "This interface may..." Change to "might"

Section 4.5.1 has the acronym "PHOP". What's this acronym? If the 
first time in the doc, please explode it.

Section 4.8 has
  " In some cases, having a full RSVP implementation running on an end
   host can be seen to produce excessive overhead.

The burden of RSVP is in the routers, not the endpoints - so the 
amount of code to be in endpoints is only about 20KB of code (per 
Fred Baker, who wrote it into IOS), so you really have to qualify 
this statement, given that most dumb wireless phones have this much 
space in memory.

My concern is people not understanding what minimal code is needed to 
run RSVP, and read this - and use it to justify why RSVP can't be on 
endpoints like IP phones, when it can easily be on phones.

Comments are welcome

Cheers,
James
IETF TSVWG co-chair

              ***********************************
     "It should NEVER be inconvenient to do the right thing"