Subject: [Tsvwg] Review of draft-ietf-tsvwg-admitted-realtime-dscp-04

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Mar 2008 16:30:40 +0000

Fred, James, Martin,

I've split my promised review of "DSCPs for capacity admitted 
traffic" into substantive comments (this mail) and nits (previous mail).

I generally support what you're trying to do here. These comments are 
designed to help get it through w-g and IETF last calls.

==============================================================================
Basically, the draft is asking the IETF to make an unnecessarily 
large set of controversial statements all bundled together into a 
standards track I-D. My reading extracts the following things this 
draft is trying to do:

1/ Recommend best practice implementation for isolating Traffic 
Aggregates that have been admission controlled from those that haven't.

2/ Point out that we only need to isolate admitted traffic where 
there's a history of mixing a non-admitted TA with it, given certain 
commonly used service classes (video) have generally been admission 
controlled while others (voice) both have and haven't.

3/ Say that the PHBs of the admitted voice TA can re-use the existing 
EF PHB, but also define what is different about this admitted TA. The 
difference is solely that edge traffic conditioning MUST involve a 
robust admission control technique, so I believe you are defining a 
per-domain behaviour here. RFC3086 says what a good PDB should 
include so you should refer to it and follow it.

4/ Say that robust admission control should include call precedence handling.

5/ Assign a global DSCP to enable the admitted-voice TA to be isolated

6/ Retrospectively define the PDBs of the video classes to state the 
assumption that they use admission control, rather than a mix of AC and non-AC.

7/ Recommend best practice for which admission control mechanisms 
provide worthwhile admission control and precedence handling.

It's up to you whether you try to submit this whole cocktail of 
fairly controversial proposals and recommendations in one go. I 
happen to agree with most of your views, but the chances of getting 
consensus on all of them at once are pretty slim. Especially given 
that a standards track assignment of a DSCP has to get through a full 
IETF last call. I suggest it would be easier to break out 4, 6 & 7 
into an informational doc, or at least demote them to appendices.

Admitted Voice service class (Items 1, 2, 3 & 5)
----------------------------
These items constitute a minimum coherent set to create a generic 
standards action that introduces an Admitted Voice service class.

I believe you are defining a simple per-domain behaviour so you 
should try to use the relevant language and concepts in RFC3086.

Retrospectively defining video as Admitted (Item 6)
------------------------------------------
The draft includes this sentence:
   "It also recommends that certain classes of video described in
    [RFC4594] be treated as requiring capacity admission as well."
Admittedly, this is on-topic, but it's a very different type of 
standards action. Instead of defining a service class that vendors 
can choose to use, it's saying everyone should assume these video 
service classes have always been admission controlled. To make such a 
retrospective statement, you have to say what the admission control 
at the ingress to a domain should do with packets that carry one of 
the video DSCPs but have a filterspec that hasn't asked for admission 
control. As you are effectively defining a PDB for these classes, you 
should have sections answering all the other questions a PDB should 
answer [RFC3086].
Suggested alternative wording:
"Given these video services are inelastic, their service definitions 
are likely to be meaningful only if traffic is also subject to 
admission control.

Precedence handling (Item 4)
-------------------
Multiple times the draft says AA is a non-optional aspect of the 
Admitted Voice service class (throughout the Abstract, Introduction, 
Definitions (CAC), Recommendations (S.3), IANA Considerations and 
Security Considerations).

Authentication and authorization are only required if you need 
precedence, so they are completely orthogonal to a draft introducing 
an admitted voice service class.

Suggested alternative wording:
"If an operator wants to provide flow or call precedence handling, 
the admission control function must also provide authentication and 
authorization."

Reasoning: Imagine a network provides free access to VoIP calls for 
all customers, but subject to admission control. It doesn't offer 
precedence. This might be an enterprise network or a public network 
in a jurisdiction where some operators are not subject to regulations 
requiring precedence. The admission control system works just fine 
without authentication and authorization. The network can stop one 
flow affecting the QoS of another even though it doesn't know (and 
doesn't care) who is making which call. So AA is truly orthogonal to 
your request for a capacity admitted service and for a DSCP.

Recommending which AC mechanisms provide worthwhile assurances (Item 7)
--------------------------------------------------------------
Slagging off everything except RSVP might be valid, but it's not 
relevant to the task at hand. The standards action is about defining 
Admitted Traffic service class(es) that can be isolated from 
non-admitted traffic (a chisel to be added to the toolkit of planers, 
band-saws etc that Diffserv provides - to use the analogy in RFCs 
4594 & 5127). If an operator needs to make this isolation, it's up to 
the operator what it considers as a robust enough AC mechanism to 
warrant using isolation.

Yes, the IETF can put together a 'project plan' on how to use this 
new chisel alongside the other 'tools' on offer. But I advise caution 
if you want to mix 'project plans' into a document defining a 
'chisel'. I would suggest that, at least, you surround such text with 
strong warning signs explaining that the reader is no longer in 
'standards action' land, but is now in 'useful guide' land.

Also, you can't just write off all the other admission control 
techniques. The efficacy of each one depends on the topology it is 
applied to. Call counting is a perfectly deterministic admission 
control mechanism for the non-meshed links of a regional access 
network (which is where my company uses it). SIP-based admission 
control can also be sufficient over non-meshed parts of a network 
(using call-counting), assuming acceptance of a SIP call triggers the 
network to police each flow's bit-rate at ingress (or the codecs are 
under network control).

Conversely, Intserv over Diffserv provides rubbish admission control 
if the DS domain has a very large hop diameter without increasingly 
heavily overprovisioned links towards the middle.

Here's an example of an argument you can avoid by being less prescriptive:
I would advise using the Admitted Voice DSCP to separate traffic 
subject to PCN-based admission control from traffic subject to only 
RFC2998 edge admission control without PCN. You might not want to advise this.

Assuming you don't want this argument to hold up this draft (I don't 
either), then I suggest you don't include the argument in the draft 
--- given few people care what the IETF says about this right now anyway.

On this basis, here's suggested wording for Section 3...

3. Section heading
Old: "Recommendations on implementation of an Admitted Telephony 
Service Class" ->
New: "Recommendations for Isolation of an Admitted Telephony Service Class"

Old: "It is the belief of the authors that either data plane PHB 
described in Section 2.1, if coupled with adequate AAA and capacity 
admission procedures as described in Section 2.2.5, are sufficient to 
provide the services required for an Admitted Capacity service class 
and an Admitted Multimedia Conferencing Service Class." ->

New: "Inelastic traffic that has not been subjected to robust 
admission control can overload links, which can make all sessions of 
the same inelastic class that pass through the link unusable. 
Therefore an Admitted Capacity service class is required to isolate 
traffic that has undergone robust admission control from traffic that 
has not. The Admitted Capacity service class uses the EF PHB, but is 
isolated from and prioritised over non-admission controlled EF 
traffic using either of the data plane queueing arrangements 
described in Section 2.1.

The only further difference from EF is that Admitted Capacity traffic 
REQUIRES a per-domain behaviour [RFC3086] that conditions the Traffic 
Aggregate at the edge of the DS domain using a robust admission 
control technique.

{Define the Admitted Multimedia Conferencing service class similarly.}

It is up to the operator to decide which of the admission control 
techniques outlined in Section 2.2 are robust enough to warrant 
isolation from non-admission controlled traffic, but we offer the 
following guidelines...
"

HTH

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does 
not necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196