Subject: [Tsvwg] RE: draft-ietf-tsvwg-rsvp-dste-00.txt review comments - Kwok's review

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Fri, 27 Jan 2006 12:04:13 +0100

Hello Kwok, 

Thanks for your review. Please see below:

>> -----Original Message-----
>> From: Kwok-Ho Chan [mailto:[email-masked]] 
>> Sent: mercredi 25 janvier 2006 01:08
>> To: Francois Le Faucheur (flefauch)
>> Cc: [email-masked]; [email-masked]; 
>> [email-masked]; Bruce Davie (bdavie); [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]; 
>> James Polk (jmpolk); Fred Baker (fred); Subha Dhesikan 
>> (sdhesika); Kwok-Ho Chan
>> Subject: draft-ietf-tsvwg-rsvp-dste-00.txt review comments
>> 
>> Authors, Chairs, Reviewers:
>> Please see below my review comments (and some suggested text) for
>> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-dste-00.txt
>> 
>> 1.  Section 1 Introduction, bottom of 3rd paragraph on page 2.
>>       "Diffserv eliminates the need for per-flow state and 
>> per-flow processing
>>       and therefore scales well to large networks."
>>       Can you add "per-flow signaling" as follows:
>>       "Diffserv eliminates the need for per-flow state, 
>> per-flow signaling,
>>       and per-flow processing, therefore scales well to 
>> large networks."

Diffserv focuses on datapath mechanisms and allows any method of
resource allocation (eg provisioning which indeed eleminates signaling,
as well as on-path admission control as per RFC2998 which keeps per-flow
signaling, as well as bandwidth brokers which may also involve some
per-flow signaling). So, to me, Diffserv itself does eliminate per-flow
state and per-flow processing in the datapath. It can be used "with" or
"without" per-flow signaling. While it is generally used "without", it
is also used very succesfully "with" per-flow signaling in environments
where the number of flows is small to medium.

So I think current text is probably correct.

>> 
>> 2.  Section 1 Introduction, 5th paragraph on page 3.
>>       "[MPLS-TE] describes how MPLS TE Tunnels... Then, CAC (Call 
>> Admission Control)
>>       is performed during the establishment of TE Tunnels to ensure 
>> they are granted
>>       their requested resources."
>>       IMHO, there are more than one kind of Admission Control:
>>       First, there is the initial setup of the TE Tunnel (reserving 
>> resources for the whole
>>       tunnel).  Which I think this paragraph is discussing.
>>       Second, there is the Admission Control of the per-flow (or per 
>> Intserv RSVP micro flow)
>>       session into the TE Tunnel (this is in the bearer/data path).
>>       Third, there is the Admission Control of the per application 
>> session (this is in the application
>>       signaling path).  I believe this is what should be called CAC 
>> (Call Admission Control).
>> 
>>       IMHO, the goodness/value of this draft is in tying these 
>> different Admission Control concepts
>>       together, it will be beneficial to distinctly clarify 
>> them up front.

I see your point that it may be confusing to talk about "Call" when we
are doing admission control of an RSVP reservation over a TE Tunnel, or
admission control of the TE tunnel itself. To avoid this confusion I
have cleaned up the document so that:
	- "Admission Control" is used whenever we talk about admission
RSVP reservations or RSVP TE tunnels.
	- "Call Amdission Control/CAC" is used only when discussing the
Voice example

Note that this draft is really focusing on one specific part which is
how to do admission control of E2E RSVP over MPLS TE tunnels. How this
may be used to achieved things like Voice CAC is described here for
information purposes. 

>>       Hence, IMHO, I think this paragraph should read as:
>>       "[MPLS-TE] describes how MPLS TE Tunnels can be 
>> established via 
>> [RSVP-TE] and
>>       how these tunnels can be used to carry arbitrary aggregates of 
>> traffic.  MPLS TE uses
>>       Constraint Based Routing to compute the path for a TE 
>> tunnel.  Adequate resources
>>       are reserved in the LSRs as requested during establishment of 
>> TE Tunnels."
>> 
>>       If this concept is acceptable by the Authors, then there are 
>> numerous places in the
>>       draft that uses "CAC" or "Admission Control" that will need to 
>> be modified.
>>       For example at bottom of page 3:
>>       "- a TE tunnel is subject to CAC and thus is effectively an 
>> aggregate bandwidth reservation"
>>       should be:
>>       "- a TE tunnel is subject to resource reservation 
>> during tunnel 
>> setup and thus is effectively
>>       an aggregate bandwidth reservation"
>> 
>>       Some of these different Admission Control was indicated in the 
>> Appendix.  But I believe they
>>       should be in the main part of the draft.

See above.

>> 
>> 3.  Section 1 Introduction, bottom of section on page 5.
>>       "- dynamic, topology-aware resource-based admission 
>> control can 
>> be provided to applications
>>          over any segment of the end to end path including the core"
>> 
>>      For the notion of topology-aware, IMHO, it is the whole network 
>> that is topology aware.
>>      This topology-aware info is not provided to the 
>> application/end-point/end-user, at least not
>>      by the mechanism of this draft.

This is not suggesting that topology-awareness is provided to
applications. This is trying to say that "topology-aware admission
control is provided to applications".

To make that real clear I have rephrased to:
"
-	applications can benefit from dynamic, topology-aware
resource-based admission control over any segment of the end to end path
including the core
"

>>      RSVP states in each hop (RSVP hop) knows only of its immediate 
>> neighboring RSVP hops,
>>      hence the topology-awareness may need to be better 
>> described here.
>>      Topology-awareness is a double edge sword, it could benefit and 
>> hinder the overall design.
>> 
>> 4.  Section 3.2 Receipt of E2E Path message By the 
>> Aggregator, bottom 
>> of section on page 9.
>>       "- addressed directly to the Deaggregator.  The destination 
>> address of the E2E Path message
>>       is set to the Deaggregator address and the Router 
>> Alert is not set..."
>>       How/when is the orignal E2E Path msg Dst IP Address get 
>> restored?  Assuming the E2E Path
>>       Msg is of the Intserv RSVP type.  Or the orignal E2E Path msg 
>> Dst IP Addr will not get restored?

Yes it is restored. It is restored by the Deaggregator.
I have added an explicit statement about that, so it reads:

"
The Deaggregator MUST forwards the E2E Path downstream towards the
receiver. In doing so, the Deaggregator MUST set the destination address
of the E2E Path message to the IP address field of the Session object
and MUST set the Router Alert.
"

Note that this is actually in line with the regular RSVP behavior (ie an
RSVP Router actually picks the destination IP address in the Session
object and tells the IP layer to use that as the destination address of
the Path message - ie it normally does not store the IP header in which
the Path message was received anyways). 

>>       The PSB and RSB structures of RSVP state machine uses the RSVP 
>> Receiver IP Address
>>       (the Path Msg Dst IP Addr) as one of the keys during PSB, RSB 
>> lookup

No. They just use what is in the RSVP objects.

 (but I think this info
>>       is also in the RSVP Session Object).  Or is the original E2E 
>> Path Msg get intercepted/hijacked
>>       mid stream and will never travel downstream from the 
>> Egress LER 
>> toward the original real E2E Path
>>       Msg receiver?
>>       This will also have impact on multicast whenever multicast 
>> needs to be considered because the
>>       Path Msg Dest IP Addr holds the multicast Group Address.
>>       This is getting complicated.

I don't think so.
Again, re-constructing the destination IP address before forwarding a
Path message is normal RSVP behavior.

>> 
>> 5.  Section 3.4 Receipt of E2E Path Message by Deaggregator, second 
>> paragraph on top of page 9.
>>       The question indicated in Comment #4 above concerning Path Msg 
>> Dest IP Addr also applies here.
>>       This may be the place to add the restoration of the original 
>> E2E Path Msg Dest IP Addr text.
 
Yes. 
Done.  See abobve.

>> 6.   Section 3.9 Example Signaling Flow, bottom of the 
>> section on page 12.
>>        IMHO, I think a note should be added below (4) indicating:
>>        "Notes: Steps (1) to (4) may be repeated if the Aggregator 
>> selects a different TE tunnel
>>        (different from the tentative TE tunnel in step (1)) as the 
>> final TE tunnel."

OK. I added
"
If final tunnel is different from tunnel tentatively selected, the
Aggregator may re-send an E2E Path.
"
Note that the Deagg may or may not also retrigger an E2E Path, the
Receiever may or may not retrigger a Resv...

>> 
>> 7.  Section 5 E2E Reservation Applicability on page 13.
>>       Typo in bullet item (2) the reference "[RSVP-AGG]" should be 
>> "[RSVP-AGGR}".

Right.

>> 
>> 8.  Section 6.1 Voice and Video Reservation Scenario, first 
>> paragraph 
>> at bottom of page 13.
>>       For clarification of Admission Control.
>>       "An example application of the procedures specified in this 
>> document is admission control
>>       of voice and video..."
>>       Can be:
>>       "An example application of the procedures specified in this 
>> document is admission control
>>       into the DS-TE tunnel by the Aggregator of voice and video 
>> sessions in environments ..."
 
I think the application is really better described in current wording:
"ie CAC of voice/video with very hogh nb of flows". Having an Aggregator
to CAC over TE tunnels is really the description of how I can achieve
this application.

>> 9.  Section 7 Optional Use of RSVP Proxy on RSVP Aggregator, 4th 
>> paragraph at bottom of page 15.
>>       "Hence, when behaving as the RSVP Proxy, the RSVP Aggregator 
>> may effectively perform resource
>>       reservation over the MPLS TE Tunnel ... even if the RSVP 
>> signaling only takes place upstream
>>       of the MPLS TE Tunnel (i.e. between the host and the 
>> RSVP aggregator)."
>>       For this, the Dst IPAddr of the per-flow RSVP Path Msg 
>> is the Aggregator?

No. It is the final destination. But an RSVP receiver Proxy may decide
to terminate the Path message and return a Resv (and do downstream CAC
on TE Tunnel).

>>       And it (the Path Msg) does not go all the way to the 
>> real media Receiver?
>>       For this, the Sender will need to know the Aggregator's IP 
>> Address. 
>> This adds complexity
>>       to the whole architecture.

No. The sender does not have to know the Aggregator's IP Address. In
fact the sender does not even know that RSVP Proxing is happening.

>> 10. Section 7 Optional Use of RSVP Proxy on RSVP Aggregator, below 
>> the diagram bottom of page 16.
>>        In (1) (i).  The text: "performs admission control over/into 
>> the TE Tunnel" is good way to indicate
>>                      which admission control this is talking about.
>>        In (3)(iii).  Does (3) have any relationship with (1) and 
>> (iii) with (1)?
>>                       How does Aggr/Deaggr/Proxy know what the 
>> parameters of Path/ResV are?
>>                       Is symmetrical reservation assumed?

There has been different proposals for RSVP proxy. They offered
differnet solution to this question (eg from simplest which assumes
symetrical reservation, to more complex which involve signaling of
reverse reservation). So it depends on the details of the Proxy
approach.

>> 
>> 11. Section 7 Optional Use of RSVP Proxy on RSVP Aggregator, 1st 
>> paragraph at top of page 17.
>>        "But regardless of the details of the call flow and of the 
>> actual RSVP Proxy approach, ..."
>>        IMHO, this paragraph sounds a bit loose and not sure 
>> of its purpose.
>>        Is it describing the requirements of what any optional use of 
>> RSVP Proxy on RSVP Aggregator are?
>>        Is it describing the features of what any optional 
>> use of RSVP 
>> Proxy on RSVP Aggregator are?
>>        Some clarification may help.  And discussion of requirement 
>> and features may help this section.
 
This is not trying to identify requirements for RSVP proxy solution.
This is explaining that "RSVP Aggregation over TE Tunnels" plays well
with the RSVP proxy concept (regardless of which actual RSVP Proxy
solution may be used/standardised by IETF).

>>        While on the topic of the features of Optional Use of RSVP 
>> Proxy on RSVP Aggregator,
>>        What is the advantage of using the RSVP Proxy approach?
>>        Is it to reduce the E2E (Intserv, application traffic sender 
>> to application traffic receiver) RSVP
>>        messages being carried as normal data packets inside 
>> the DS-TE tunnels?
>>        What other advantage does use of RSVP Proxy have over just 
>> using E2E/Intserv RSVP inside
>>        the DS-TE tunnel (Sending the E2E/Intserv RSVP messages all 
>> the way from the application
>>        traffic sender to the application traffic receiver, 
>> inside the 
>> DS-TE tunnels when aggregation is
>>        needed/performed)??
>>        Does the extra complexity worth the trouble?

One advantage is that it localises RSVP signaling between end-device and
Agg/Degg instead of enbd-to-end. Where end-to-end RTT is long, this can
enhance Post-Dial-Delay.
The network administrator will be the one to decide whether this is
worthwhile. The point here is that nothing additional ahs to be
specified as part of "RSVP Aggregation over TE": if you don't want to
use proxy, fine. If you want to use proxy, this is fine too.
Some operators have expressed interest in combining the proxy function,
so I believe it is useful to describe how the two can play together.

>> 
>> 12. Section 7 Optional Use of RSVP Proxy on RSVP Aggregator, bottom 
>> of section on page 17.
>>        For (iii).  Please notice this splitting the RSVP signaling 
>> into two disjoint halves may just provide
>>        half the solutions.  

No. It does provide the full solution ie it achieves CAC on every
segment (including the core) and in both direction.

>>Is the propagational delay of E2E RSVP 
>> messages between Aggregator and
>>        Deaggregator really that bad?

We don't have to decide that. Network Administrator will make the call
in his/her environment.

>> 13. Appendix A at bottom of page 22.
>>       "In this example, in addition to behaving ...  So when a PE 
>> receives a Path message from a GW,
>>       it does not propagate the Path message any further."
>>       What is the Dest IPAddr of this Path message?

Address of remote GW.

>> 
>> 14. Appendix A at bottom of page 22.
>>        "In this example, in addition to behaving ... and generates a 
>> ResV message back towards
>>        the GW to confirm resources have been reserved over 
>> the DSTE tunnel."
>>        This is somewhat different from normal RSVP functionality.
>>        The DS-TE tunnel is at the Egress port of the 
>> PE/Proxy/Aggregator.
>>        Normally the resource of this Egress port is reserved when a 
>> ResV message
>>        is received from the downstream (RSVP definition of 
>> downstream) RSVP hop,
>>        NOT when a Path message is received from upstream (RSVP 
>> definition of upstream)
>>        of an Ingress port.

The idea is not to reserve resources when the Path is received. But
rather to reserve resources on the egress link when the Resv is
generated by the Rescievr Proxy (which basically behaves exactly as if
it had received the Resv from a downstream node). So again this depends
on the specifics of the RSVP poroxy solution, but is quite in line with
existing RSVP functionality.

>> 
>> 15. Appendix A at bottom of page 23.
>>       "[SIP-RSVP] discusses how network ... These preconditions 
>> require that the participant reserve
>>       network resources before continuing with the session.  The 
>> reservation of network resources are
>>       performed ..."
>>       IMHO,
>>       "These preconditions require that the underlying application 
>> traffic transport verify it can
>>       provide the required QoS before continuing with the 
>> session.  This can be accomplished using
>>       network resource reservations.  The reservation of network 
>> resources can be performed ..."
>>       is a better way to describe this.
>> 

This text is coming verbatim from the [SIP-RSVP] RFC abstract. I think
it is quite fine.

>> 16. Appendix A, 1st paragraph at top of page 26.
>>       "We note that admission control of vice calls over the core 
>> network capacity is ..."
>>       IMHO, this paragraph provides the different notions of 
>> Admission Control but should not
>>       just call them CAC.  Hence this can be expanded and added into 
>> the front of the document.

As discussed above.

>> 
>> 17. Appendix A, 3rd paragraph at top of page 26.
>>        "It is also possible for the GWs to use ...
>>         - DSTE tunnels are ...
>>         - Aggregate RSVP reservations from GW to GW are subject ..."
>>         When RSVP Proxy is used (which is what this Appendix is 
>> describing), this is really GW to PE only.

Edited text to:
"
-	Aggregate RSVP reservations (for the calls from one GW to
another GW) are subject to  Admission Control over the DSTE tunnels (as
per the "RSVP Aggregation over TE Tunnels" procedures defined in this
document) 
"

>> 
>> Please excuse my ignorance if some of the answers/solutions to above 
>> comments are obvious.
>> 
>> Hope these comments/text help improve the quality of this draft.
>>

Yes, I think it will help in making this a more readable document.
Thanks.

Francois
 
>> You can post these comments to the TSVWG list if that is the 
>> correct procedure.
>> 
>> Regards!
>> -- Kwok --
>> 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg