[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-ietf-policy-req-00.txt
Here are my comments on the abovementioned draft:
First of all - Hugh - really good draft. Thanks for putting the time into
it. My comments are mostly (surprise) regarding the absence of the signaled
QoS model. Admittedly, this is a policy draft in general, rather than a QoS
policy draft specifically, but - I do think that it is important to consider
the fact that QoS has two complementary models - signaled and provisioned,
that affect its policy requirements. It is likely that other policy clients
(such as IPSec will have similar issues). And - I do think that the
signaling model is underrepresented and that it presents requirements which
will be neglected unless it is well represented.
To this end, i've been working with Hugh, Luis and Shai on adding specific
text to the policy rquirements draft (which I allude to but do not directly
include, below). The text consists of a couple of usage cases and some words
on the role of signaled QoS in policy management.
I've inserted relevant portions of the draft text (indicated by '>') and
follwoed them with my comments on the section. For reference, i've preceeded
each comment with the page number from the original draft from which the
text was excerpted.
>
> Internet Draft Hugh Mahon
> Expiration: March 2000 Hewlett-Packard
> File: draft-ietf-policy-req-00.txt
>
> Requirements for a Policy Management System
>
>
> +-------+
> |Policy |
> |UI |
> | |
> +-------+
> ^
> |
> V
> +------------------------+
> |Policy Repository |
> | |
> | |
> +------------------------+
> ^ ^
> / |
> / |
> V V
> +---------+ +---------------+
> |Policy | Policy | Policy |
> |Decision | Consumers | Consumer 1 |
> |Point | | |
> +---------+ +---------------+
> ^ ^ ^
> COPS RSVP| |COPS, \
> Client type | |SNMP, TelnetCLI, etc.
> V V V
> +------------+ +-----------+ +-----------+
> |RSVP enabled| Policy | Policy | | Policy |
> |device | Targets | Target A | | Target B |
> | | | | | |
> +------------+ +-----------+ +-----------+
>
(pg. 6) This diagram implies that a device is either RSVP enabled (COPS/RSVP
served) or strictly provisioned (COPS/SNMP served). In fact, many of the
more interesting devices may provide both provisioned QOS (for non-signaled
traffic) and signaled QoS (for signaled trafic) simultaneously. These
devices will likely interact with their PDPs or policy consumers for both
purposes simultaneously. This model should be explicitly acknowledged.
>
> To provide further examples, the Policy Consumer receives
> policy intended for a Policy Target and processes the pol-
> icy to allow the Policy Target to enforce the policy. The
> Policy Consumer may use the policy interactively, that is,
> directly use the policy information to make a decision each
> time an event occurs which requires an enforcement decision
> (such as the arrival of a packet). In this real-time pol-
> icy usage scenario the Policy Consumer is acting in the
> role of the PDP (Policy Decision Point) as described in the
> COPS architecture (see [COPSFRAME]).
(pg. 8) In this paragraph, the event that triggers a policy decision is the
arrival of a packet. While it may be reasonable to trigger PDP decisions
based on packet arrival, under certain conditions, it seems that a much more
manageable trigger is the arrival of a signaling message, such as RSVP.
Implementations of policy based on an RSVP message trigger already exist.
The usage is specified in draft-ietf-rap-cops-rsvp-05.txt and in
[COPSFRAME]. I would prefer that the example in this paragraph cite the
arrival of an RSVP message as a trigger.
>
> 2. The Policy Consumer may receive policy information and
> convert this into configuration information for a man-
> aged element (e.g., a router) and then configure the
> device to act in accordance with the policy informa-
> tion. This scenario is more likely to occur with
> DiffServ related policies (that is, non-signaled QoS
> mechanisms) than with IntServ related policies.
(pg. 8) The last statement implies that non-signaled is equivalent to
diffserv and that signaled is equivalent to intserv. This is misleading.
Refer to
http://www.ietf.org/internet-drafts/draft-ietf-issll-diffserv-rsvp-03.txt.
This draft explains clearly that RSVP is a signaling protocol, diffserv is a
traffic handling mechanism. Intserv is also a trafic ahndling mechanism +
guidelines on admission control. Signaling can be used with diffserv and
with intserv.
A general comment - in my opinion, the policy system will have to consider
the network to include a number of superimposed resource 'pools'. Let's say
that QoS policy wants to enable high quality QoS (such as required by
telephony or interactive video), medium quality QoS (such as might be
allotted to mission critical applications that cannot specify their precise
resource requirements), low quality QoS (such as better than best-effort)
and just plain old best-effort, simultaneously. For high quality QoS,
signaling is pretty much required (unless the network administrator is
willing to significantly over-provision, which, at least on WAN links is not
an option). Medium quality QoS can benefit from signaling (e.g. a mission
critical app signaling for the null service, as specified in
http://www.ietf.org/internet-drafts/draft-ietf-issll-nullservice-00.txt as
well. Low quality might be strictly provisioned (not signaled). If a PDP
configures a device to support both high quality and low quality traffic, it
must preserve the integrity of the high quality guarantees. The high quality
traffic can be readily policed (since specific conversations are either
admitted or rejected and classification information for each conversation is
readily available). On the other hand, provisioned QoS traffic is not
readily policed. For example - a rule which says "mark all traffic that
looks like A Fairly Important Web App as AF", could result in an arbitrary
amount of trafic being marked as AF. If too much traffic is marked based on
the provisioned rules, it could seize resources that should be reserved for
the signaled QoS guarantees. So - when a network supports both signaled and
non-signaled QoS, it's really important that the policy system recognize
that all resources, whether issued by signaled QoS or by provisioned QoS,
are consumed from a common pool. It should allow the network administrator
to divvy up the network resources between virtual pools, such that resources
granted by provisioning do not take away from resources granted by
signaling. One of the steps in achieving this is probably to not allow
signaling mechanisms to mark traffic for the ame codepoints as provisioning
mechanisms. I'd like to see the concept of such resource sub-pools mentioned
in any doc that tackles QoS policy. It may or may not be appropriate for a
document that tackles policy in general, but the implications of the
requirment should be considered.
> 3. Policy Management in Action
>
> The following list describes the expected sequence of actions
> in a policy based management system. Each aspect will be dis-
> cussed further in this section and following sections of this
> document. In addition, later sections will discuss aspects of
> policy not necessarily apparent in a simple description of
> policy operation.
>
> A. Administrator authors new policy (or edits existing pol-
> icy)
>
> B. Administrator associates policy with Policy Targets.
>
> C. Policy and association with Policy Targets is stored in
> repository.
>
> D. For each of the Policy Targets, a Policy Consumer is
> notified that new policy is available for the Policy Tar-
> get.
>
> E. The Policy Consumer obtains the policy. See below for a
> detailed description of the actions of the Policy Con-
> sumer.
>
> F. For each Policy Target which received policy information,
> the Policy Consumer provides status information back to
> the Administrator about policy deployment; success, or
> failure and information about the failure.
(pg. 9) I'm not sure just how to incorporate it, but - it seems that this
high level description should recognize both models of signaled policy and
provisioned policy and should explain the actions associated with each.
Perhaps the description is high enough a level that it already encompasses
both, but it leaves me feeling that it does not.
>
> 3.3.2. Policy Notification
>
> Also described above is the need to have policy deliv-
> ered to Policy Consumers in a timely manner.
>
> Network Administrators currently configure devices in
> real time. Even though policy management provides addi-
> tional features, Administrators will still want the man-
> agement process to occur in human terms (for feedback
> this means within a few seconds). In order for policy
> to be received by the Policy Consumer and provide feed-
> back to the Administrator in such a time frame the Pol-
> icy Consumer must either poll the Policy Repository at
> short intervals or be notified that there is information
> to retrieve from the repository.
>
> Polling would place a burden on the Policy Consumer (and
> the system it is implemented on), the Policy Repository
> (and its host), and the network. Polling is an effec-
> tive, if inefficient, way to determine if there is new
> policy. To reduce the cost of polling, the polling
> interval can be increased, so that queries are performed
> less often, but this reduces the ability to receive pol-
> icy in a timely manner.
>
> Notification would be more efficient than polling, and
> could be done to support timely delivery.
(pg. 17) The arrival of RSVP signaling messages is a natural policy
notification mechanism.
> 4.3.1. Conflict (Inconsistency) Between Policies
>
> When multiple policies are deployed throughout the net-
> work it is possible that the behavior specified in one
> location will not be the same as behavior specified in
> another location.
>
> +----------+ +----------+
> |Net Elem A| |Net Elem B|
> LAN Alpha | | LAN Beta | | LAN Gamma
> +----------+Int1 Int2+------------+Int3 Int4+----------
> | | | | |
> +--+-----+ | | | |
> |User PC | +----------+ +----------+
> | |
> +--------+
>
> Figure 5.
>
> In Figure 5 there are two network elements, A and B,
> which are connected together serially, and traffic may
> pass from LAN Alpha through LAN Beta to LAN Gamma. If a
> user on LAN Alpha expects to have the same QoS when com-
> municating with systems on LAN Beta and LAN Gamma, then
> the subset of policy (i.e., rules) pertaining to the
> user's traffic (based on address, traffic type, or other
> characteristic) deployed on the interfaces of network
> elements A and B must agree.
>
> If all of the LANs are being maintained by one IT
> department, and the user has contracted for 200 kbps for
> traffic to systems on LAN Gamma, then the policies
> deployed on interfaces 1, 2, 3, and 4 must all support
> at least that much throughput for the user. For
> instance, if policy deployed to Int2 and Int4 allow
> 200kbps for traffic coming from the user's machine, and
> policy deployed to Int1 and Int3 only allowed 150kbps of
> traffic to the user's PC, then the policies deployed to
> Int1 and Int3 could be in conflict with the policies
> deployed to Int2 and Int4.
>
(pg. 22) Top-down provisioning should be used to establish upper limits on
local resource usage. For example - "not more than 10% of this link's
capacity should be allocated to the EF PHB (otherwise it won't be low
latency)". Signaled QoS is the mechanism for coordinating currently
allocated resources within those limits, consistently, along an end-to-end
path. Topology aware admission control is one of the major value-adds that
signaling brings to policy management systems. This should be acknowledged
in specific usage cases. I have provided text addressing this, separately.
>
> - Destination IPaddress
> - Destination IPport
> - Destination IPsubnet
> - IPaddress (matches either source or destination)
> - IPport (matches either source or destination)
> - IPsubnet (matches either source or subnet)
> - Source IPaddress
> - Source IPport
> - Source IPsubnet
> - Type of Service - IP precedence bits
>
> Source and destination subnet may be inferred from the
> IP address information (the condition would contain the
> subnet mask to allow determination of affinity).
>
> Devices with sufficient capability may be able to look
> at other portions of the packet, below layer 3 and above
> layer 3. Such other information that may be observed
> include:
>
> - Application Traffic (if not clear from the
> Port number used,
> or more detailed than the Port number reveals)
> - Protocol Type (IP, IPX, ARP, DECNet,
> Appletalk, SNA over Ether)
> - URL
> - VLAN ID
>
> These conditions allow an Administrator to identify who
> (i.e., users associated with IP addresses) or what
> (i.e., what applications) are using the network, or
> both, and specify what type of QoS is to be provided to
> those uses of the shared network resources. See section
> 5 for examples.
(pg. 32) Again, this is where signaled QoS shines. Signaled QoS messages
transit each PEP in the data path, carrying the user id, application (and
sub application) id, src/dest addr/port, required service type, etc. They
even carry SPIs so that IPSec encrypted data can be recognized by PEPs.
Policy management systems should snoop these messages to help populate
robust mappings from user, app to IP addr and port. I have provided text to
describe this functionality.
>
> F. The Policy Consumer processes the Policy Data and
> configures the Policy Target(s) using the appropri-
> ate mechanism(s) for the Target(s). (An interface
> between the Policy Consumers and Policy Targets,
> requiring a protocol or not, is not a requirement.)
>
(pg. 35) Why not? I would have thought this to be one of the most desirable
interfaces to standardize. Isn't this COPS/RSVP or COPS/PR (or whatever),
from figure 1?
> A simple approach would be to give priority to traffic to
> or from Accounting during these times. To do this the
> Administrator could author a policy such as the following:
>
> if (((trafficToOrFrom AccountingSubnet) &&
> (dayOfMonth in last10days))
> ||
> ((trafficToOrFrom AccountingSubnet) &&
> (monthIn [April, July, October, January]) &&
> (dayOfMonth in [1-15])))
> then
> priority = high
> endif
>
> Expressions in the condition list such as 'trafficToOrFrom'
> and AccountingSubnet are abstractions which maybe presented
> by management implementations to provide understandable yet
> accurate representations of management goals. Such repre-
> sentations as 'AccountingSubnet' would be specified else-
> where in the Policy Management Application or may be taken
> from other established mappings that already exist in the
> environment (e.g., directory entries, etc.). Such high
> level representations may exist in an implementation but
> are not required. The requirement is the information that
> goes into the Policy Schema, which is discussed below.
>
> In the above Policy Rule the traffic is being tested for
> coming from or going to the subnet for the Accounting
> department. If the traffic is coming from or going to the
> AccountingSubnet, and it is the last 10 days of the month,
> or is the first fifteen days of the month after the end of
> a quarter, then the traffic is given high priority.
>
> Instead of comparing against a subnet, the test could be
> for a set of machines, or could be for a specific applica-
> tion.
>
> The above Policy Rule would be translated into an actual
> set of device independent information which conforms with
> the Policy Schema.
>
> Since this Policy Rule is likely not the only Policy infor-
> mation that would be deployed to a set of devices in the
> network, this example will add other Policy Rules in the
> set to be deployed to a target (as described in section
> 2.1). First is the representation in Policy Schema terms
> of what the above Policy Rule would translate into:
>
> Rule 1: provide high QoS for traffic to or from the
> AccountingSubnet during the last 10 days of the
> month, or first 15 days after the end of a
> fiscal quarter
>
> if (((IPsubnet 192.168.12.0/255.255.248.0) &&
> (dayOfMonth in last10days))
> ||
> ((IPsubnet 192.168.12.0/255.255.248.0) &&
> (monthIn [April, July, October, January]) &&
> (dayOfMonth in [1-15])))
> then
> priority = 6
> endif
>
(pg. 45) This is the kind of policy that one is limited to when signaled QoS
is disregarded. It suffers from several deficiencies. For a start - it
requires all accounting users to be on the same subnet. If they were not, it
would require potentially management intensive tables listing all accounting
users and their IP addresses. It also allows the accounting users to use
their valuable share of the network resources to play doom, when - in fact,
the intent was to allow the resources for their acounting work. The
classification information that can be gleaned by listening to signaling
messages offers significant improvements in the rules which can be
generated, automates their generation and eliminates the management burden.
Signaling messages identify users and the application that they are running
and provide the detailed classification criteria to install.
> 5.3. Traffic Classification With Packet Conditions
>
> The use of IP Port values in the IP packet header allows
> understanding what kind of traffic the packet represents
> (as long as one of the Port values is a well-known or reg-
> istered port). If traffic is going to a well-known port it
> is going to a server for that type of application. If it
> is going from a well-known port it is going to a client of
> that application. Use of the srcIPport, destIPport, and
> IPport conditions as described earlier allow an Administra-
> tor to classify traffic by type. (Other ways will are
> described in section 4.7.2.)
>
(pg. 53) This breaks down when apps use volatile/transient ports and when
flows are encrypted using IPSec. Using signaling to glean classification
information solves both problems.
> Use of addresses (or names) allows designation of individ-
> ual machines, or groups of individual machines. Use of
> subnet identifiers allows a shorter designation of groups
> of people or systems involved in specific types of work
> (e.g., Accounting, R&D, etc.).
>
(pg. 53) This breaks down when DHCP reassigns addresses, on multiuser
machines, with NAT, when users with common requirements do not share
subnets, etc. Again - signaling fixes this problem.