Subject: [Tsvwg] Nits in draft-ietf-tsvwg-admitted-realtime-dscp-04

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Mar 2008 15:53:17 +0000

Fred, James, Martin,

I've split my promised review of "DSCPs for capacity admitted 
traffic" into nits (this mail) and substantive comments (next 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.

==============================================================================
General terminology: The draft refers to the proposed service 
class(es?) with the following different names:
- Capacity-Admitted Traffic
- Admitted Telephony service class
- Admitted Service Classes
- VOICE-ADMIT
- EF2
It would be useful to add these to the definitions section, if you 
mean different things by these. Otherwise, if they are all the same 
thing, pls make them consistent or explain why different words are 
useful for the same thing.

General structure: I found Section 2.2 listing the five Capacity 
Admission Control techniques very confusing, because it came under 
the general section heading of "Implementations of the Admitted 
Service Classes", but only in Section 3 did you suddenly say 
(paraphrasing) "None of that stuff we just described is a good enough 
implementation of the Admitted Service Class except that in Section 2.2.5."
1. Intro

Para 3: Video class doesn't have to be server-user. Can be user-user.
Para 4: Clarify that these are all US-specific terms

1.2 Problem

Para 1: Not clear what you mean by 'edge network'.

1.3 Proposed Solution

"The IETF is asked to differentiate, in the Telephony Service, 
between sessions that are originated without capacity admission ..."

The section heading and this text seems to be a hang-over from when 
you were making your case for a new codepoint. For standards track, 
we need a standard that can either be complied with or not, so you 
now need to simply define the semantics of the service class and 
assign the codepoint.

"...without network-originated control..." what is this meant to imply?

2. Implementation of the Admitted Service Class

Suggested new title: "Candidate Implementations of the Admitted Service Class"

2.1 Potential implementation of EF in this model

"There are at least two possible ways to implement the Expedited 
Forwarding PHB in this model." ->
"There are at least two possible ways to implement isolation between 
the Capacity Admitted PHB and the Expedited Forwarding PHB in this model."

Ironically, the very long sentence starting "The reason this is 
necessary is that there is currently confusion in the industry..." is 
too long and too confusing.

Fig 2 and the text describing it both need to say which PHB is which, 
out of EF and EF2 (for the avoidance of doubt).

Para 6: "...datagrams containing video data are relatively large 
(generally the size of the path MTU)" ->
"...datagrams conaining video data can be relatively large (often of 
variable sizes up to the path MTU)"

2.2 Capacity admission control

"There are five major ways that capacity admission is done or has 
been proposed to be done in real-time applications." ->

"There are five major ways that capacity admission is done or has 
been proposed to be done for real-time applications. Each will be 
described below, then Section 3 will judge which ones are likely to 
meet the requirements of the Admitted Telephony service class."
(Otherwise it's very unclear what's going on.)

"There is also a mechanism that has been proposed for enhancing the 
probability of call completion in a preferential manner. ..."
I suggest this whole long para is given a new section 2.2.6 or 
something. It's a bit odd having a corner-case coming before the five 
main scenarios.

2.2.2 para 2: Garbled sentence.
"SIP provides the option to go down another path, to admit its 
servers at layer 7, have no awareness of lower layer connectivity, 
resulting in a divorce from infrastructure knoweldge - save for 
[RFC3312] which binds the two, but only at the endpoints." ->

"SIP seems to provide an alternative admission control mechanism, but 
its servers are at the application layer and have no awareness of 
lower layer connectivity - save for [RFC3312] which binds the two, 
but only at the endpoints. Therefore SIP alone cannot control 
capacity admission robustly."

2.2.2 para 3, 1st sentence: Garbled.

2.2.3 Suggested updated wording for whole PCN section:

{I suggest this is placed after S.2.2.5 on Distributed Capacity AC, 
as it builds on the concepts described there.}

2.2.x Admission Control using Pre-Congestion Notification (PCN)

If only the boundary nodes of a DS domain make admission control 
decisions [RFC2998], the interior links have to be overprovisioned to 
reduce the chance that an unusual pattern of traffic will focus on an 
interior link and degrade admitted flows. For every hop further away 
from the admission control at both edges, overprovisioning of the 
links has to increase linearly [Reid]. But, still, overprovisioning 
merely reduces the chance of overload rather than eliminating the possibility.

The IETF is standardising pre-congestion notification (PCN 
[PCN-arch]) so that queues in the interior of a high speed DS domain 
can mark the IP headers of packets in bulk as traffic of a DS class 
approaches a configured threshold rate. Then, even without 
overprovisioning, admitted flows cannot be degraded whatever the 
pattern of demand, because capacity admission control at the edges of 
the DS domain can determine actual traffic conditions in the interior 
by monitoring for PCN markings.

The PCN approach is not applicable for the small links around the 
edges of a network where a link showing no sign of congestion can be 
tipped into overload by a single extra flow. Nonetheless, on high 
speed links PCN provides equivalent capacity admission control to the 
Intserv Controlled Load service without any flow state or flow 
processing on interior nodes, thus addressing the scalability 
concerns of [RFC2208]. PCN is currently only defined for unicast forwarding.

PCN standardises the essential aspects of numerous approaches 
proposed over the years, many referenced in [PCN-arch]. It was 
initially defined for use with RSVP signalling, but deployment 
scenarios are also being worked on using NSIS and the ETSI TIPSPAN 
resource admission control framework (RACF).

2.2.4 3rd sentence ambiguous

"...can keep track of simple bookeeping functions apart from network 
elements such as routers." ->
"...can keep track of simple bookeeping functions separately from 
network elements such as routers."

2.3 1st sentence

"Emergency Telecommunications Service, the US Department of Defense's 
Assured Service, and e-911 each call for..." ->
"Emergency Telecommunications Service, the US Department of Defense's 
Assured Service and e-911, the US emergency telephony service,..."
(Only using US examples is fine as long as you say they are US-only)

"...each call for..." ->
"...each require..."
(Using the phrase 'call for' here could be confused with the calls 
made by users of these services.)

"In the PSTN, GETS operates..." ->
"In the US PSTN, GETS operates..."

2.3 3rd para, last sentence:
"In essence any capacity admission policy..." ->
"Any typical capacity admission policy..." ->
(This statement depends on the SLAs given to the other traffic.)

2.3 5th-8th paras, 1st sentences of each para:
"If capacity admission as described in Section 2.2.x is in use..." ->
"If capacity admission using {call counting|PCN|etc} (Section 2.2.x) 
is in use..."
(Easier to read without having to refer back to which section number is which)

2.3 Delete 6th para last sentence:
"In any event, this is only applicable in domains in which the law of 
large numbers applies."
(I've now said this in the new S2.2.3, and it's not relevant in this 
section which is specifically about precedence.)

2.3 7th para last sentence:
"...to the extent that is variable..." ->
"...to the extent that it is variable..."

4. IANA Considerations.

"It implements the Telephony Service Class described in [RFC4594] at 
lower speeds and is included in the Real Time Treatment Aggregate 
[RFC5127] at higher speeds."
(These two RFCs are informational. I don't think you mean to make a 
standards action depend on informational stuff.)

Additional References

[Reid] Andy Reid, "Economics and Scalability of QoS Solutions," BT 
Technology Journal 23(2) (April, 2005) (access requires a fee)

HTH

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196