Subject: Re: [Tsvwg] Review of RSVP Proxy Approaches

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 2 Apr 2008 19:25:00 +0200

Hi James,

On 24 Mar 2008, at 21:02, James M. Polk wrote:
> TSVWG
>
> This is my WG chair review of
> http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-rsvp-proxy-approaches/

Thanks for this thorough review.

Specific responses are included below. A new version with all the  
changes announced below will be posted soon.

>
> 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"?

I don't think there is a well-established definition of what is RSVP  
v1 and if the many subsequent extensions are part of v1 or make it  
RSVP v2 or RSVP v1.5. But I see that perhaps "conventional RSVP" is  
not precise enough either. So I'm proposing the following rewording:
"
The Resource ReSerVation Protocol (RSVP) can be used to make end-to- 
end resource reservations in an IP network in order to guarantee the  
quality of service required by certain flows. RSVP assumes that both  
the data sender and receiver of a given flow take part in RSVP  
signaling. ...
"

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

done.

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

Added the following (to fit in better with current text using  
unidirectional description):
"(for example from the sender to the network edge, or from edge to  
edge, or from the network edge to the receiver)."

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

The paragraph has been reworded to:
"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."

At this stage, we just want to introduce the concepts of Sender Proxy  
and Receiver Proxy (and not so much talk about the use cases). The  
use cases (including edge-to-edge) are covered later.

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

I assume you mean there ought to be a specific reference to the  
relevant NSIS spec discussing Proxy.
A reference to section 4.8 "Proxy Mode " of nsis-qos-nslp has been  
added.

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

I see that the current text ("are not meant to replace the standard  
RSVP ") can be confusing and suggest there is some change in RSVP  
signaling.
This text has been updated to:
"
The concepts presented in this document are not meant to deprecate  
the traditional RFC2205 RSVP end-to-end model: end-to-end RSVP  
reservations are still expected to be used whenever possible.  
However, RSVP Proxies are intended to facilitate RSVP deployment  
where end-to-end RSVP signaling is not possible.
"

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

fixed. (it was not RFC2119 language BTW)

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

yes. The idea is that section 2 simply describes the notion of  
proxies and the subsequent sections discusses how they are actually  
used.

The text has been cleaned up a bit (eg "somehow" has ben removed).  
And we already have the following sentence:
"Mechanisms to operate an RSVP Sender Proxy are discussed later in  
this document."
so we should be OK in terms of hinting that details are coming.

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

fixed

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

Right. References for SIP & RSTP have been added.

I prefer we do not add SDP because:
	- SDP is used by SIP & RTSP anyways
	- I see SDP as a method for describing session attributes, but not  
as fully fledge application level signaling (ie you can't setup a  
session using SDP only).  In that sense it is not comparable to SIP &  
RTSP.
	- this seems consistent with RFC4566 (section 3) that describes SDP  
and RTSP as "application-level protocol"

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

Because the diagram is only considering/showing a unidirectional  
reservation.
The following diagram (Fig 6) illustrates the case you mention with  
reservations in both directions.
So this is already covered.

> If the first PATH is only to trigger the PATH in the reverse  
> direction,

Yes, in Figure 5, the first Path message is purely there to trigger  
reverse reservation. By definition, this is what we call a "Path  
triggered Sender Proxy for 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?

as with "regular" RSVP, R is expected to refresh the Left-to-Right  
Path state. So it is meant to keep sending refreshes. To make this  
more explicit I've added:
"More precisely, the RSVP Proxy can take the creation (respectively,  
maintenance and teardown) of a Path state by the receiver as the cue  
to create (respectively, maintain and teardown) a Path state towards  
the receiver. "

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

Good point.
I added the following:
"
Note also that the Path messages generated by the receiver need to  
transit via the RSVP Sender Proxy that is on the path from the sender  
to the receiver. In some topologies, this will always be the case:  
for example where the sender is on a stub network hanging off the  
RSVP Sender Proxy or where there is no asymetric routing (such that  
if a RSVP Sender Proxy is on the path from receiver to sender, then  
it is also on the path from sender to receiver). In some topologies  
(such as those involving asymetric routing), this may not always  
happen naturally. Measures to ensure this does happen in these  
topologies are outside the scope of this document."

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

Let's say that we have a unidirectional application (say streaming  
video from streamer to Set Top Box). And we have a non-RSVP capable  
sender (Streamer). Then one could use the flow of Figure 5. One would  
not use the flow of figure 6 because there is no reservation to be  
established in the direction from STB towards streamer.

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

the endpoint does not have to send "two PATHs". The endpoint just  
start sending a PATH (and the refreshes it). Then the endpoint:
	* will happen to receive Resv messages indicating a reservation has  
been establsihed for traffic sent by that endpoint
	* will happen to receive Path messages allowing that device to issue  
Resv messages (if it so desires) to establish a reservation for  
traffic received by that endpoint.

 From that endpoint viewpoint, it all appears as if it was  
communicating with a regular RSVP capable remote endpoint. ie that  
endpoint is indeed Proxy-unaware.

>
>
> 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 this is precisely the point we are trying to make. Whether  
the Proxy triggers the reservation from inspecting SIP or other  
protocols, it does not (generally) participate in the signaling  
itself so it can not communicate with the endpoint. So we're saying,  
is that case, one approach is to Remark traffic DSCP for the flow  
that no longer has a reservation (that way the other flows that have  
reservations are protected).

I've slightly reworded the text to make it clearer:
"Note however, that in case of reservation failure, the inspection- 
triggered RSVP Proxy does not have a direct mechanism for notifying  
the application (since it is not participating itself actively in  
application signaling) so that the application is not in a position  
to take appropriate action (for example terminate the corresponding  
session)."

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

the inspection-triggered proxy knows the flow (since it established a  
reservation for that flow in teh first place). If the reservation  
goes down and the flow/session is still in place, the Proxy can  
program a local classifier/remarker that resets the DSCP of all  
packets for that flow.

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

There is no need for signaling the DSCP itself. It is just a local  
remarking done by the Proxy.

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

sorry, i couldn't parse this sentence.

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

agreed. changed to "..widely adopted approach...".

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

more effectively than... if you don't include the STUN attributes.

The old text brought up the topic of new STUN attributes in two  
places. I've edited that so it is only brought up once. It now reads:
"For our purposes of triggering RSVP Proxy behavior, we rely on ICE's  
connectivity check which is based on the exchange of STUN Binding  
Request messages between hosts to verify connectivity (see section  
2.2 of <"I-D.ietf-mmusic-ice">). The STUN message could also include  
(yet to be specified) STUN attributes to indicate information such as  
the bandwidth and application requesting the flow, which would allow  
the RSVP proxy agent to create an appropriately-sized reservation for  
each flow. Including such new STUN attributes in the ICE connectivity  
check messages would facilitates operation of the RSVP Proxy.

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

It is not what is intended.

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

Right.
Reworded to "This allows reasonably effective synchronisation between  
RSVP reservations handled by the RSVP Proxies and the application  
running on non RSVP-capable endpoints. "

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

reworded to :
"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 be used to carry the (yet to be defined) STUN  
attributes mentioned earlier to indicate the flow bandwidth, thereby  
providing a benefit similar to the ICE connectivity check."

Also, we already have a note about the fact that those attributes are  
yet-to-be defined :
"The corresponding extensions to ICE and STUN for such a STUN- 
triggered RSVP Proxy approach are beyond the scope of this document. "

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

Done.

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

changed to "can".

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

done.

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

Fair point. I believe this section was introduced for exhaustivity.  
But it may indeed be conveying a misleading message.
Let me talk to some of my co-authors to discuss whether we shouldn't  
just remove this section (or at least make it clear that the  
rationale for that sort of approach is debatable).

>
> Comments are welcome
>
>
> Cheers,
> James
> IETF TSVWG co-chair
>
>              ***********************************
>     "It should NEVER be inconvenient to do the right thing"
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 03 Apr 2008 00:17:11 -0500

Francois

Comments in-line

>the data sender and receiver of a given flow take part in RSVP

I like this

>edge, or from the network edge to the receiver)."

This is good

>the data receiver(s). We refer to this entity as the RSVP Receiver

I like this text too

>use cases (including edge-to-edge) are covered later.

fair comment, and I like how you've addressed this

>A reference to section 4.8 "Proxy Mode " of nsis-qos-nslp has been

good

>where end-to-end RSVP signaling is not possible.

very good

>fixed. (it was not RFC2119 language BTW)

I thought so, but wasn't sure

>so we should be OK in terms of hinting that details are coming.

I'm ok with this

>         - SDP is used by SIP & RTSP anyways

right

>session using SDP only).  In that sense it is not comparable to SIP &

but it is the MIME encoded payload of both SIP and RTSP that carries 
SDP which is the only part of the IP packet that is codec bandwidth 
requirement aware, and the only part of the IP packet that can 
request for a reservation to be established.  In other words, SIP and 
RTSP don't care what type of "dialog" (which is an SDP "session" 
technically) is present in the payload part of the signaling, just as 
SIP and RTSP don't care at all which codec is used. It is the SDP 
that cares about both.

This is nitpicking a bit, but I believe this is technically accurate too

>So this is already covered.

ok

>triggered Sender Proxy for REverse direction".

Does the sender of the PATH know it's communicating with a "Path 
triggered Sender Proxy for Reverse direction"? In other words, is the 
Proxy merely intercepting the Path, or does the sender know where the 
Proxy is (in order to know it will be received by a or by the Proxy)?

If this can be clearer, it should be made so.

>to create (respectively, maintain and teardown) a Path state towards

ok

>topologies are outside the scope of this document."

this is what I commented on above, so you can ignore that comment

I like this text

>established in the direction from STB towards streamer.

ok

>the endpoint does not have to send "two PATHs".

really?

Don't you have this expectation to get bi-directional reservations established:

1-   A --> Path--> Proxy      B
2-   A<-- Path <-- Proxy      B
3-   A -->Resv--> Proxy      B
4-   A--> Path--> Proxy       B
5-   A<--Resv <--Proxy       B

      A<==2-way res=====>B

It's the second (message #4)

         A--> Path--> Proxy       B

that I don't understand how A knows to send.

If I'm wrong, I'm wrong - but this seems to me to be how you'd get a 
bi-directional reservations established.

>The endpoint just

I'm ok with that goal

>to take appropriate action (for example terminate the corresponding

good

>program a local classifier/remarker that resets the DSCP of all

ok

>remarking done by the Proxy.

ok

>>http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp- attribute-02.txt

I think this is covered already, so this point isn't important here anymore

>>   For unicast flows, [I-D.ietf-mmusic-ice] is an already widely- adopted

that's the ticket

>more effectively than... if you don't include the STUN attributes.

this isn't clear to me, but I understand it now.

>check messages would facilitates operation of the RSVP Proxy.

ok

>It is not what is intended.

I hope not  ;-)

>running on non RSVP-capable endpoints. "

great

>providing a benefit similar to the ICE connectivity check."

this is better...

>triggered RSVP Proxy approach are beyond the scope of this document. "

sorry, I missed this the first time

>>sentence starting with "This interface may..." Change to "might"

good

>rationale for that sort of approach is debatable).

very good

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 3 Apr 2008 19:22:44 +0200

Hi James,

<points of agreement clipped>.

> but it is the MIME encoded payload of both SIP and RTSP that  
> carries SDP which is the only part of the IP packet that is codec  
> bandwidth requirement aware, and the only part of the IP packet  
> that can request for a reservation to be established.  In other  
> words, SIP and RTSP don't care what type of "dialog" (which is an  
> SDP "session" technically) is present in the payload part of the  
> signaling, just as SIP and RTSP don't care at all which codec is  
> used. It is the SDP that cares about both.
>

I'd still rather avoid bundling together SIP/RTSP and SDP. So I've  
added a separate sentence for SDP. It now reads:
"
SIP (RFC3261) and RTSP (RFC2326) are examples of application level  
signaling protocol. SDP (RFC4566) is an example of session  
description protocol that can be used by the application level  
signaling protocol and from which RSVP reservation parameters  
(addresses, ports and bandwidth) can be derived.
"

> that I don't understand how A knows to send.

there is no need for message #4.
In other word, message #1 (Path) serves two purposes:
	- it serves as a trigger for the "Path-triggered RSVP Sender  
Proxy..." to generate a Path message towards A pretending it has been  
generated by B (message #2)
	- it serves as a regular Path message from A to B. The "RSVP  
Receiver Proxy"  uses this as a cue to generate a Resv in reverse  
direction (message #5)
In this case, the idea is that A is not aware that there is an RSVP  
Proxy in the picture.

But I think the point you're getting at is the following:
	* while in this case of bidirectional reservations, A may be  
blissefully unaware of RSVP Proxies, A has to be "aware" of Proxies  
and behave "differently" in the case of unidirectional reservation  
(ie in Figure 5).
That is true.

The following text has been added to clarify all that:
"
In the case where reservations are required in both directions (as  
shown in Fig 6), the RSVP-capable device simply needs to behave as a  
regular RSVP sender and RSVP receiver. It needs not be aware that an  
RSVP Proxy happens to be used and the Path message it sent for the  
forward reservation also acts as the trigger for establishment of the  
reverse reservation. However, in the case where a reservation is only  
required in the reverse direction (as shown in Fig 5), the RSVP- 
capable device has to generate Path messages in order to trigger the  
reverse direction reservation even if no reservation is required in  
the forward direction. Although this is not in violation with  
RFC2205, it may not be the default behavior of an RSVP-capable device  
and therefore may need a behavioral change specifically to facilitate  
operation of the Path-Triggered Sender Proxy for Reverse Direction.
"

>> rationale for that sort of approach is debatable).

Will confirm soon the proposal for that one.

Francois

---

From: Ping Pan <[email-masked]>
Date: Thu, 03 Apr 2008 16:05:27 -0700

Francois Le Faucheur IMAP wrote:
>> requirement aware, and the only part of the IP packet that can request 
>> for a reservation to be established.  In other words, SIP and RTSP 
>> don't care what type of "dialog" (which is an SDP "session" 
>> SIP and RTSP don't care at all which codec is used. It is the SDP that 
>> cares about both.
>>
> I'd still rather avoid bundling together SIP/RTSP and SDP. So I've added 
> a separate sentence for SDP. It now reads:
> "
> signaling protocol. SDP (RFC4566) is an example of session description 
> protocol that can be used by the application level signaling protocol 
> and from which RSVP reservation parameters (addresses, ports and 
> bandwidth) can be derived."
> 

I think James may be referring to this:

http://tools.ietf.org/html/draft-ietf-mmusic-qos-identification-01

in which SDP is used to negotiate reservation mechanisms between endpoints.

In this case, it's the applications would detect the availability of 
RSVP, and encode in SDP during QoS negotiation. RSVP should not care 
about the existence of SDP.

Does it make sense?

- Ping

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 04 Apr 2008 11:37:03 +0200

> bandwidth) can be derived."

However, in the case of RTSP only what flows and their bandwidth can be 
determined from SDP. The addresses and ports are established in the 
SETUP request and responses.

(As RTSP update author)

Cheers

Magnus Westerlund

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

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 4 Apr 2008 13:18:32 +0200

>> (addresses, ports and bandwidth) can be derived."
>
> However, in the case of RTSP only what flows and their bandwidth  
> can be determined from SDP. The addresses and ports are established  
> in the SETUP request and responses.

Noted.

Rephrased to:
"
SDP (RFC4566) is an example of session description protocol that can  
be used by the application level signaling protocol and from which  
some of the RSVP reservation parameters (addresses, ports and  
bandwidth) might be derived."
"
Thanks

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 4 Apr 2008 13:41:08 +0200

Hi Ping, (and James)

> in which SDP is used to negotiate reservation mechanisms between  

Right: This would be applicable when endpoints do support RSVP (or  
NSIS) natively.
In this document, we discuss application level signaling as a  
mechanism to trigger RSVP proxies (for example when discussing  
"Application_Entity-controlled-proxy) in which case the endpoints  
would not use anything like draft-ietf-mmusic-qos-identification.

Perhaps an interesting question is what happens when:
	- one endpoint is RSVP-capable and makes use of RFC3312 (and  
possibly of draft-ietf-mmusic-qos-identification)
	- the other endpoint is not RSVP-capable and is helped by an RSVP Proxy
I'd imagine that the Application Entity would simply do some SIP  
"adjustements" between the two sides.
But is this not a general SIP question anyways regardless of RSVP  
proxies?
  (eg doesn't SIP have to handle the case where one endpoint supports  
RFC3312 and the other endpoint doesn't)
Is this indeed implicitely/explicitely dealt with by SIP?
If yes, then how about we just add one sentence in the RSVP Proxy I-D  
mentioning that we would be in such a situation in the case where we  
have a RSVP Proxy on one side and not on the other side, but then  
"regular" SIP approach for dealing with that situation (ie endpoints  
with different capabilities) would be used?

Thanks

Francois

>
> In this case, it's the applications would detect the availability  
> of RSVP, and encode in SDP during QoS negotiation. RSVP should not  
> care about the existence of SDP.
>
> Does it make sense?
>
> - Ping

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 4 Apr 2008 13:51:15 +0200

James and all,

> Will confirm soon the proposal for that one.

I had a conversation with Jukka and we plan to do the following:

	- remove 4.8. There are already a lot of flavors of Proxies. The  
flavor described in section 4.8 of using a super-light-weight  
protocol on endpoint instead of RSVP does not really seem that useful  
considering modern endpoint capabilities (including all sorts of  
portable/mobile devices) and the very small footprint of an RSVP  
endpoint stack.
	- add a statement somewhere in the introduction to:
		(i) insist that we don't promote RSVP Proxies instead of end-to-end  
RSVP, but only describe Proxies for where e2e is not possible
		(ii) capture some of the discussion above about the footprint of  
RSVP endpoint stack to address common misconceptions that it is  
difficult/heavy to implement RSVP on end devices.

Let us know if anyone has issues with this plan.

Thanks

Francois

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Apr 2008 09:42:28 -0700

> -----Original Message-----
> From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
> Sent: Friday, April 04, 2008 4:41 AM
> To: Ping Pan; James M. Polk
> Cc: Francois Le Faucheur IMAP; tsvwg list IETF; Dan (dwing) Wing
> Subject: Re: [Tsvwg] Review of RSVP Proxy Approaches
> 
> Hi Ping, (and James)
> 

SIP's default handling of that situation -- where one endpoint
supports a feature which is not supported by the other endpoint --
is to not use the feature.  So, in that case, RSVP wouldn't be
used to set up that call at all.

> with different capabilities) would be used?

Something to the effect of:

  In some cases, the endpoint may not natively support RSVP.  To
  handle this case, the RSVP proxy would perform the RSVP 
  operations on behalf of the endpoint and the SIP signaling would 
  be fixed up (using, for example, a SIP B2BUA) so that it appeared 
  -- to the remote SIP network -- that the endpoint does support 
  RSVP.

-d

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 8 Apr 2008 11:54:41 +0200

>   -- to the remote SIP network -- that the endpoint does support

Makes sense. We'll add some text to that effect in the section  
discussing application_entity-controlled proxy.
That will cover both Precondition (RFC3312) and draft-ietf-mmusic-qos- 
identification.

Thanks

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 10 Apr 2008 16:29:22 +0200

> That will cover both Precondition (RFC3312) and draft-ietf-mmusic- 
> qos-identification.

Here is the text that I included (actually in section 3) to reflect  
this discussion. Please let me know if it needs correction/enhancements:

"
Some application level signaling protocols support negotiation of QoS
    reservations for a media stream.  For example, with [RFC3312],
    resource reservation requirements are explicitely signaled during
    session establishment using SIP and SDP.  Also,
    [I-D.ietf-mmusic-qos-identification] defines a mechanism to  
negotiate
    which resource reservation mechanism is to be used for a particular
    media stream.  Clearly, these reservation negotiation mechanisms can
    be invoked and operate effectively when when both ends support RSVP
    (and obviously RSVP Proxies are not used).  When both ends do not
    support RSVP (and RSVP proxies are used at both ends) these
    mechanisms will simply not be invoked.  In the case where one end
    supports RSVP and the other does not (and is helped by an RSVP
    Proxy), the application level signaling entity supporting the non
    RSVP capable end might use the reservation negotiation
    mechanisms in such a way that the non RSVP capable end (helped
    by an RSVP Proxy) appears to the remote end as an RSVP capable
    device.  This will ensure that the RSVP capable end is not
    discouraged to use RSVP because the remote end is not RSVP capable.
    In the case of SIP, the application level entity may achieve this by
    taking advantage of the "segmented" Status Type of [RFC3312] and/or
    by implementing a SIP [RFC3261] Back-to-Back User Agent (B2BUA).
"

Francois

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 10 Apr 2008 16:37:17 +0200

Hi,

> protocol on endpoint instead of RSVP does not really seem that  
> useful considering modern endpoint capabilities (including all  
> sorts of portable/mobile devices) and the very small footprint of  
> an RSVP endpoint stack.
> 		(i) insist that we don't promote RSVP Proxies instead of end-to- 
> end RSVP, but only describe Proxies for where e2e is not possible

Below is the text that has been added to section 1 to reflect the  
above discussion. Let us know if you have comments.

"
    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 end to end model allows
    the most effective synchronization between the reservation and
    application requirements.  It is also worth noting that RSVP
    operations on endsystems is considerably simpler than on a router,
    and consequently that RSVP implementations on endsystems are very
    lightweight (particularly considering modern endsystems  
capabilities,
    including mobile and portable devices).  For example, endsystem RSVP
    implementations are reported to only consume low tens of  
kilobytes of
    code space).  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.
"
Francois

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 Apr 2008 14:10:58 -0500

>    by implementing a SIP [RFC3261] Back-to-Back User Agent (B2BUA).

I like it

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 Apr 2008 14:13:21 -0500

At 09:37 AM 4/10/2008, Francois Le Faucheur IMAP wrote:
>>                 (i) insist that we don't promote RSVP Proxies 
>> instead of end-to- end RSVP, but only describe Proxies for where 
>> e2e is not possible

This is very well stated.

James