Subject: draft-ietf-issll-diffserv-rsvp-04.txt

From: "Nabil Seddigh" <[email-masked]>
Date: Mon, 10 Apr 2000 11:34:29 -0400 (EDT)

I was recently pointed to the last call for the
draft: <draft-ietf-issll-diffserv-rsvp-04.txt>

I apologize for the late comments but have
a few issues with the draft that I thought I 
should bring out - if anything, to clarify my
own understanding. I don't think any of my
comments point to any major holes in the 
draft - just editorial comments, comments
to tighten up loosely made statements and
a few comments which might deserve more 
serious consideration (especially in the multicast 
area) :)

Comments are interspersed among the draft text. 

Regards
Nabil Seddigh
[email-masked]

----------------------------------------

> Internet Draft
> Expires: September, 2000
> Document: draft-ietf-issll-diffserv-rsvp-04.txt         March, 2000
> 
> 
>   A Framework For Integrated Services Operation Over Diffserv Networks
> 
>[....DELETED.....]
> 
> 2.1 Integrated Services Architecture
> 
>    The integrated services architecture defined a set of extensions to
>    the traditional best effort model of the Internet with the goal of

Section 2.2 is missing!!

> 2.3 RSVP
> 
> [.......DELETED..................]
> 
>    The following factors have impeded deployment of RSVP (and the
>    Intserv architecture) in the Internet at large:
> 
>    1. The use of per-flow state and per-flow processing raises
>       scalability concerns for large networks.
> 
>    2. Only a small number of hosts currently generate RSVP signaling.
>       While this number is expected to grow dramatically, many
>       applications may never generate RSVP signaling.
> 
>    3. The necessary policy control mechanisms -- access control,
>       authentication, and accounting -- have only recently become
>       available [17].
> 

While the above few factors impeded deployment
of Intserv, there were clearly many other important factors
that hampered acceptance of Intserv as the sole
technology solution to provide IP-QoS:

1. Route Pinning - Intserv required nailing down of 
   a path between end-hosts. This connection-oriented
   approach was foreign to IP networks.

2. It did not provide a solution for what constituted
   a large portion of Internet traffic - short flows
    with elastic behaviour. The overhead of end-to-end
   reservation on a per-flow basis is too large a cost
   to be incurred by flows that typically transmit
   no more than a few packets. 

3. Intserv focused very much on host-to-host connections
   and did not seem to allow for the fact that many
   service agreements would be at a more aggregated 
   level with intermediate management points such the
   gateway between the enterprise and the service 
    provider or carrier.  This seemed to be a clear
   non-fit with the business model of the Internet.

4. There was difficulty matching the 2 existing service
    models of Intserv against the requirements for 
   TCP-based apps. While for voice or video, apps
   would have a sense of their requiremetns 
   (i.e BW, jitter/delay tolerance), this was not
   quite the case for TCP-based apps. How would a 
   server responding to HTTP requests know what
    traffic profile parameters to request from the
   network.

> 
> 2.7 The Framework
> 
> [.................DELETED....................]
> 
>
> In one extreme the Diffserv region is pushed all
>    the way to the periphery, with hosts alone having full Intserv
>    capability. In the other extreme, Intserv is pushed all the way to
>    the core, with no Diffserv region.
> 

I have some difficulty understanding the statement:
"...hosts alone having full Intserv capability".
If I understand the scenario that the sentence depicts, 
we have all Diffserv routers with RSVP signaling in the 
end-hosts. Surely this is not Intserv? There's not
a single Intserv router along the path between
source and destination. Maybe it would be better
to reword the sentence along the lines:

"In one extreme the Diffserv region is pushed all
the way to the periphery, with hosts simply 
signalling the Diffserv region for resources."

> 
> 3.1 Resource Based Admission Control
> 
>  [...DELETED....]
>
> To further
>    understand this issue, consider a Diffserv network region providing
>    only aggregate traffic control with no signaling. In the Diffserv
>    network region, admission control is applied implicitly by
>    provisioning policing parameters at network elements. 

The following statement could be misinterpreted as equating
admission control and policing (of course both are very
different things):

"...admission control is applied implicitly 
by provisioning policing parameters at network elements"

In the above, I would say that some form of static admission
control was performed when the PDP allowed the administrator
to enter the traffic filter and associated profile into the
database. Presumably the PDP wouldn't allow an infinite
number of SLSs (or equivalent filter & traffic profile)
to be entered into its DB. It must have some way of limiting
the SLSs based on some notion of what the network can
support. This I would term as static admission control. 

Once the SLS has been admitted and associated filters/traffic
profiles installed, the POLICER then ensures that the
traffic profile is adhered to by the traffic stream. 

So infact, we do have some form of static admission control
that is very explicit! What is currently lacking in
Diffserv is dynamic admission control that is triggered
when a flow is started - either via RSVP signaling or
other means. 

To clarify matters, suggest replacing the term 
explicit admission control with something like
explicitly signaled dynamic admission control.

> For example, a
>    network element at the ingress to a Diffserv network region could
be
>    provisioned to accept only 50 Kbps of traffic for the EF DSCP.
> 
>    While such implicit admission control does protect the network to
>    some degree, it can be quite ineffective. For example, consider
that
>    there may be 10 IP telephony sessions originating outside the
>    Diffserv network region, each requiring 10 Kbps of EF service from
>    the Diffserv network region. Since the network element protecting
>    the Diffserv network region is provisioned to accept only 50 Kbps
of
>    traffic for the EF DSCP, it will discard half the offered traffic.
>    This traffic will be discarded from the aggregation of traffic
>    marked EF, with no regard to the microflow from which it
originated.
>    As a result, it is likely that of the ten IP telephony sessions,
>    none will obtain satisfactory service when in fact, there are
>    sufficient resources available in the Diffserv network region to
>    satisfy five sessions.
> 
>    In the case of explicit admission control, the network will signal
>    rejection in response to requests for resources that would exceed
>    the 50 Kbps limit. As a result, upstream network elements
(including
>    originating hosts) and applications will have the information they
>    require to take corrective action. The application might respond by
>    refraining from transmitting, or by requesting admission for a
>    lesser traffic profile. The host operating system might respond by
>    marking the application's traffic for the DSCP that corresponds to
>    best-effort service. Upstream network elements might respond by re-
>    marking packets on the rejected flow to a lower service level. In
>    some cases, it may be possible to reroute traffic over alternate
>    paths or even alternate networks (e.g. the PSTN for voice calls).
In
>    any case, the integrity of those flows that were admitted would be
>    preserved, at the expense of the flows that were not admitted.
Thus,
>    by appointing an Intserv-conversant admission control agent for the
>    Diffserv region of the network it is possible to enhance the
service
>    that the network can provide to quantitative QoS applications.
> 

The problem in the above paragraph is not that there is
no explicit admission control. Certainly there must have been
some form of static admission control to determine that
50Kbps of EF traffic could be admitted at this ingress.
However, the problem is that there also needs to
be run-time (dynamic) admission control on a more 
granular (per-flow) basis to determine who gets access
to the 50Kbps. Thus, there are really 2 levels of admission
control - both are explicit. One is static and works on 
the granularity of the SLS. The other is dynamic (run-time) 
and works on a per-5-tuple flow.

> 
> 3.3.1 Host Marking
> 
>    [.......DELETED....] Furthermore, if IPSEC encryption is used,
>    the host may be the only device in the network that is able to make
>    a meaningful determination of the appropriate marking for each
>    packet.
> 

Suggest the above statement be somewhat clarified.
IPSEC is an issue only for classification
based on Layer4-7 information. Many SLSs are specified
based on source/dest IP addresses & masks. IPSEC
is not an issue for Layer-3 based classification.

>    Host marking requires that the host be aware of the interpretation
>    of DSCPs by the network. This information can be configured into
>    each host. However, such configuration imposes a management burden.
>    Alternatively, hosts can use an explicit signaling protocol such as
>    RSVP to query the network to obtain a suitable DSCP or set of DSCPs
>    to apply to packets for which a certain Intserv service has been
>    requested. An example of how this can be achieved is described in
>    [14].
> 
> 3.3.2 Router Marking
> 
>    In the case of router marking, MF classification criteria must be
>    configured in the router. This may be done dynamically, by request
>    from the host operating system, or statically via manual
>    configuration or via automated scripts.
> 

I'm not quite clear what constitutes "MF classification criteria"?
Is this the filters on the router? If so, does PDP or Policy
Management infrastructure deserve a mention in addition to
manual configuration & CLI scripts?

> 
>    There are significant difficulties in doing so statically.
>    Typically, it is desirable to allot service to traffic based on the
>    application and/or user originating the traffic. 

Suggest changing the word "typically" to "in some cases" :)
In many cases, SLS filters will be based on the IP address of
the enterprise gateway as opposed to based on applications
or individual users. In this case, all the subsequently
mentioned issues become mute.

> 
> 4.2 Service Mapping
> 
> [..........DELETED...............] 
> 
>    In our framework, Diffserv regions of the network are analogous to
>    the 802.1p capable switched segments described in [5]. Requests for
>    Intserv services must be mapped onto the underlying capabilities of
>    the Diffserv network region. Aspects of the mapping include:
> 
>     - selecting an appropriate PHB, or set of PHBs, for the requested
>       service;
>     - performing appropriate policing (including, perhaps, shaping or
>       remarking) at the edges of the Diffserv region;
>     - exporting Intserv parameters from the Diffserv region (e.g. for
>       the updating of ADSPECs);

If I understood correctly, the above seems to say that 
Diffserv regions MUST update ADPSEC. This seems like quite
a strong requirement. Firstly it is unclear whether 
the draft is expecting each router along the path in
the Diffserv region to update ADSPEC or whether only
the border routers will update ADSPEC. Secondly, I'm
not sure such a requirement will be that easy to 
mandate for Diffserv-capable routers. 

Can the requirement be softened and more details provided
on who exactly updates the ADSPEC?

> 
> 4.2.3 Microflow Separation
> 
>    Boundary routers residing at the edge of the Diffserv region will
>    typically police traffic submitted from the outside the Diffserv
                                             ^^^^
    Extra "THE"                         ^^^^

[.............DELETED...................]

> 
>    2. Providing per microflow policing at the border routers - this
>    approach tends to be less scalable than the previous approach. It
>    also imposes a management burden on the Diffserv region of the
>    network. However, it may be appropriate in certain cases, for the
>    Diffserv boundary routers to offer per microflow policing as a
>    value-add to its Intserv customers.
> 

Just a comment! The above makes it sound like it is undesirable
to have microflow policing in border routers. This is 
certainly true. However, the scenarios in this document depict
the diffserv region as a homogeneous entity. In reality,
it will consist of multiple individual domains each with
their own border routers. If indeed Intserv/Diffserv
interoperation is to be successful, some form of
micropolicing will be required for border routers.

Certainly if flows are to be admitted on a per-flow
basis then policing needs to be performed on a per-flow
basis. In the absence of route-pinning this will be
essential. Edge routers can police the end-host. However,
if border routers have no microflow policers what
will prevent DS domains from aggregating more flows
over a specific adjacent link between domains?

> 
> 4.3 Resource Management in Diffserv Regions
> 
>    A variety of options exist for management of resources (e.g.,
>    bandwidth) in the Diffserv network regions to meet the needs of
end-
>    to-end Intserv flows. These options include:
> 
>     - statically provisioned resources;
>     - resources dynamically provisioned by RSVP;
>     - resources dynamically provisioned by other means (e.g., a form
of
>       Bandwidth Broker).

I think the draft would benefit from clarifying the 
usage of the term "provisioned resources". In my mind,
provisioning resources conjures images 
queue weights and buffer parameters configuration.

Based on reading the following paragraph, I get the
sense, the draft is really talking about "who gets access" to 
the "provisioned resources".

> 
> 5.2 RSVP-Aware Diffserv Network Region
> 
>    In this example, the customer's edge routers are standard RSVP
>    routers. The border router, BR1 is RSVP aware. In addition, there
>    may be other routers within the Diffserv network region which are
>    RSVP aware. Note that although these routers are able to
participate
>    in some form of RSVP signaling, they classify and schedule traffic
>    in aggregate, based on DSCP, not on the per-flow classification
>    criteria used by standard RSVP/Intserv routers. It can be said that
>    their control-plane is RSVP while their data-plane is Diffserv. 

Suggest removing the last line above :) The explanation earlier
in the paragraph seems quite sufficient. The last line is 
more confusing than clarifying!

> 
> 5.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region
> 
>    Border routers might not use any form of RSVP signaling within the
>    Diffserv network region but might instead use custom protocols to
>    interact with an "oracle". The oracle is a hypothetical agent that
>    has sufficient knowledge of resource availability and network
>    topology to make admission control decisions. 

Why usage of the word "HYPOTEHTICAL"? There may be questions
about the maturity or scalability of such technology but
different forms of the "oracle" exist today in universities, 
research labs and advanced technology groups.
Suggest removing the bias in the above paragraph :)

> 
> 6.2 Protection of Intserv Traffic from Other Traffic
> 
>    Network administrators must be able to share resources in the
>    Diffserv network region between three types of traffic:
> 
>    a. End-to-end Intserv traffic  - this is typically traffic
>    associated with quantitative QoS applications. It requires a
>    specific quantity of resources with a high degree of assurance.
> 
>    b. Non-Intserv traffic. The Diffserv region may allocate resources
>    to traffic that does not make use of Intserv techniques to quantify
>    its requirements, e.g. through the use of static provisioning and
>    SLSs enforced at the edges of the region. Such traffic might be
>    associated with applications whose QoS requirements are not readily
>    quantifiable but which require a "better than best-effort" level of
>    service.
> 
>    c. All other (best-effort) traffic
> 
>    These three classes of traffic must be isolated from each other by
>    the appropriate configuration of policers and classifiers at
ingress
>    points to the Diffserv network region, and by appropriate
>    provisioning within the Diffserv network region.  To provide
>    protection for Intserv traffic in Diffserv regions of the network,
>    we suggest that the DSCPs assigned to such traffic not overlap with
>    the DSCPs assigned to other traffic.
> 

The above is certainly one way of looking at things. Another
way is to say that a Diffserv region has 3 types of traffic:

1. Quantitative
2. Qualitative
3. Best Effort

Traffic originating from Intserv would fit into the first
type of Diffserv traffic. However, there's no need to isolate
Intserv traffic from other traffic that is carried overly 
"purely" diffserv networks but also has quantitative requirements.

It seems to be far too strong a requirement to ask Diffserv
providers to isolate Intserv traffic internally.

> 7. Multicast

I have a few concerns with this whole section because
I'm not sure how feasible the proposed solutions might
be. Solution 5 seems to be the only solid solution 
in this section.

> [.............DELETED.....................]
>
>    Consider the following reference network:
> 
> 
>                                              Non-Diffserv region 2
>                                                        ________
>                                                       /        \
>                                                      |          |
|---|
>                 ________         _____________       |
|-|Rx1|
>                /        \       /          |--\      |---|      |
|---|
>               /          \     /          /|BR2\-----\ER2|     /
>        |---| |        |---|   |---|  |--|/ |---|      \--|____/
>        |Tx |-|        |ER1|---|BR1|--|RR|      |       ________
>        |---| |        |-- |   |---|  |--|\ |---|      /--|     \
>               \          /     \          \|BR3/-----|ER3|      |
|---|
>                \________/       \__________|--/      |---|
|-|Rx2|
>                                                      |          |
|---|
>        Non-Diffserv region 1   Diffserv region        \        /
>                                                        \______/
> 
>                                              Non-Diffserv region 3
> 
>               Figure 2: Sample Multicast Network Configuration
> 
> 
>    The reference network is similar to that of Figure 1. However, in
>    Figure 2, copies of the packets sent by Tx are delivered to several
>    receivers outside of the Diffserv region, namely to Rx1 and Rx2.
>    Moreover, packets are copied within the Diffserv region in a
"branch
>    point" router RR. In the reference network BR1 is the ingress
router
>    to the Diffserv region whereas BR2 and BR3 are the egress routers.
> 
>    In the simplest case the receivers, Rx1 and Rx2 in the reference
>    network, require identical reservations. The Diffserv framework
[18]
>    supports service level specifications (SLS) from an ingress router
>    to one, some or all of the egress routers. This calls for a "one to
>    many" SLS within the Diffserv region, from BR1 to BR2 and BR3. 

The above gives the mistaken impression that with today's
Diffserv specs it is possible to provide a one-to-many SLS 
(in this case one-to-two) for multicast traffic. While it
is possible to do a one-to-two SLS with VPN-like unicast 
traffic, this is not the case for multicast. In fact,
supporting a one-to-two (or more) SLS for multicast requires 
new additions to Diffserv. One such example appears in:

http://www1.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt

> 
>    These problems can be tackled by the following mechanisms:
> 
>    1. If some Intserv-capable routers are placed within the Diffserv
>    region, it might be possible to administer the network topology and
>    routing parameters so as to ensure that branch points occur only
>    within such routers. These routers would support MF classification
>    and remarking and hold per-flow state for the heterogeneous
>    reservations for which they are the branch point. Note that in this
>    case, branch point routers would have essentially the same
>    functionality as ingress routers of an RSVP-aware Diffserv domain.
> 

It seems to me that the above solution would be an 
administrator's nightmare. First, how would you identify such
key points? Won't they change based on the composition of
group membership. Second, won't you have different points
for different multicast groups (the multicast tree of each
group will probably have a different topology)? 

It seems to me that the above solution would only work
if the multicast groups were quite static and 
different groups had the same tree - neither or which
seems to be a given! 

>    2. Packets sent on the "non-reserved" branch (from RR towards BR3)
>    are marked with the "wrong" DSCP; that is, they are not demoted to
>    best effort but retain their DSCP. This in turn requires over
>    reservation of resources along that link or runs the risk of
>    degrading service to packets that legitimately bear the same DSCP
>    along this path. However, it allows the Diffserv routers to remain
>    free of per-flow state.
> 
> 

This is not really a solution to the problem :)
Suggest this point is removed. 

Essentially this point bolsters the conclusion 
that we cannot support heterogeneous service levels
(or bandwidht levels within the same service type)
for multicast. 

>    3. A combination of mechanism 1 and 2 may be an effective
>    compromise. In this case, there are some Intserv-capable routers in
>    the core of the network, but the network cannot be administered so
>    that ALL branch points fall at such routers.
> 

If solution 2 is removed, this solution reduces to solution 1 :)
Suggest this solution is also removed.

> 
> 7.2 Multicast SLSs and Heterogeneous Trees
> 
>    Multicast flows with heterogeneous reservations present some
>    challenges in the area of SLSs. For example, a common example of an
>    SLS is one where a certain amount of traffic is allowed to enter a
>    Diffserv region marked with a certain DSCP, and such traffic may be
>    destined to any egress router of that region. We call such an SLS a
>    homogeneous, or uniform, SLS. However, in a multicast environment,
a
>    single packet that is admitted to the Diffserv region may consume
>    resources along many paths in the region as it is replicated and
>    forwarded towards many egress routers; alternatively, it may flow
>    along a single path. This situation is further complicated by the
>    possibility described above and depicted in Figure 2, in which a
>    multicast packet might be treated as best effort along some
branches
>    while receiving some higher QOS treatment along others. We simply
>    note here that the specification of meaningful SLSs which meet the
>    needs of heterogeneous flows and which can be met be providers is
>    likely to be challenging.
> 
>    Dynamic SLSs may help to address these issues. For example, by
using
>    RSVP to signal the resources that are required along different
>    branches of a multicast tree, it may be possible to more closely
>    approach the goal of allocating appropriate resources only where
>    they are needed rather than overprovisioning or underprovisioning
>    along certain branches of a tree. This is essentially the approach
>    described in [15].
> 
> 

Again, the following draft provides examples of 
meaningful SLS for multicast traffic in Diffserv:

http://www1.ietf.org/internet-drafts/draft-leecy-multicast-egress-limit-00.txt