Subject: Re: [Tsvwg] Accepting draft-baker-tsvwg-admitted-voice-dscp as WG item

From: dimitri papadimitriou <[email-masked]>
Date: Mon, 04 Dec 2006 10:18:00 +0100

RFC 3935 states

"   The mission of the IETF is to produce high quality, relevant
    technical and engineering documents that influence the way people
    design, use, and manage the Internet in such a way as to make the
    Internet work better.  "

this document incorporates as part of its introduction / definition 
network architecture concepts (CAC, UNI, NNI, etc.) that go well beyond 
pure voice traffic / telephony adaptation over the IP environment it targets

henceforth, outside of what it proposes in terms EF traffic processing
it should first receive a better architectural articulation from IAB

thanks,
- d.

ps: the document mentions WRR which is fair iff equal weights and equal 
& fixed packet sizes over all flows (to allocate bandwidth fairly, 
requires a priori knowledge of the average packet size for each queue) 
not sure this is what operators would like to see in particular like 
positioned ... would be better to mention "classes of scheduling" 
techniques time stamp (WFQ, WF2Q, WF2Q+, etc.) and round robin based 
(under the xRR acronym)

Magnus Westerlund wrote:

> This is a call for input on accepting An EF DSCP for Capacity-Admitted 
> Traffic (draft-baker-tsvwg-admitted-voice-dscp) as WG item. Please 
> provide any input both positive and negative at the latest on Wednesday 
> the 6th of December.
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> 
> 
> .
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 06 Dec 2006 19:25:13 +0000

Magnus, Fred,

I also support this becoming a w-g draft. An important subject.

Here's my review points too:

1/ The central point of the draft is just one sentence in the first para of 
section 3. However, it suddenly (and unnecessarily) becomes vague at this 
point.
                                                                    If
    preemption is in view, as described in section 2.3.5.2 or [RFC4542],
    this provides the tools for carrying out the preemption.

Here, you need to spell out how separate policers would achieve 
pre-emption; and/or how separate priorities would (it's perhaps obvious but 
needs saying), and which is appropriate for different cases.

2/ The draft should make it clearer whether EF-ADMIT is given a separate 
treatment:- because it is admission controlled at flow granularity, or
- because it is traffic from 'special' flows that happen to be admission 
controlled at flow granularity.

You say that 'special' flows can be given precedence at control plane 
level. So I assume the fact they are 'special' flows is not the motivation 
for needing the DSCP. Rather any flows that have been through fine 
admission control (including special ones) deserve isolation from those 
that haven't. This seemed clear when you presented it in San Diego, but a 
number of places in the draft imply otherwise. It seems muddled (e.g. last 
sentence of 2nd para of the Intro).

3/ I understand there are also requirements in some jurisdictions not to 
separately identify emergency traffic in the data plane (otherwise it would 
be vulnerable to targeted attack). So the distinction in my point 2/ above 
is important. EF-ADMIT is NOT an indication of control plane flow 
precedence. Or are you saying it might be?

4/ When working through the details of whether we needed separate 
codepoints for admission controlled EF traffic and bulk policed EF traffic 
in PCN, I came to the same conclusion - that a separate DSCP was needed - 
however with an extra nuance...

EF traffic can overload a particular interior node's queue for two reasons:
i) traffic can just happen to concentrate at one queue sometimes due to an 
unusual traffic matrix
ii) re-routes following failures can bring more traffic than normally 
expected to an interior queue

Fine-grained AC prevents the first problem, ie only the bulk policed 
(assumption & call-counting) styles of AC are vulnerable to it.

But all forms of AC require something to be done with the excess traffic 
brought to a queue following a re-route {Note 1}.

So there seems no particular reason to reward EF-ADMIT with any special 
treatment following a re-route (assuming it does NOT represent control 
plane flow precedence). But it does seem reasonable to reward EF-ADMIT 
traffic during a traffic matrix anomaly.

One way to approximate this behaviour is to run both EF and EF-ADMIT 
through the same policer, but give EF-ADMIT scheduling priority over EF. 
This would be a third case in your section 2.1. It has the advantage that 
the sum of the two traffic classes may fit through one combined policer, 
even though one or the other wouldn't have fitted through two separate 
policers summing to the same policed rate ('multiplexing is good').

The rationale is that a re-route tends to produce huge overload, whereas an 
odd traffic matrix might still fit within a combined policer but still 
jitter the admission controlled traffic.

{Note 1: In the case of distributed AC, flows over pinned routes that have 
failed due to re-routes may be torn down and data discarded rather than 
re-routed. But by design, two of the styles of fine-grained admission 
controlled traffic are either always (probing style AC) or temporarily 
(centralized AC) decoupled from knowledge of route changes.}

Detailed points
---------------
I agree with David Black that it has some structural problems - it has a 
lot of tutorial in it, which perhaps could be relegated to appendices or 
something. It certainly needs to describe potential CAC solutions in order 
to say which ones EF-ADMIT would be applicable to. But then it also gets a 
bit side-tracked into using the draft to say what you think is best, what 
you don't like about particular approaches, etc etc.

For instance, while the last para of section 3 (RSVP is cool) might be 
true, it's not relevant to the draft. There's also a lot of unnecessary 
value judgement in section 2.2.

* Abstract:
separate ... separate
from which ... from

* I agree with Dimitri that the terminology of CAC, calls, UNI, NNI etc 
grates a bit. As we're talking about flows not calls, it's also incorrect.

* End of 2.1: It's nice to have a video example - unless you decide this is 
going to be solely about voice.

* 2.2.3 "Edge..." would be a more general term than "End-point capacity 
admission performed by probing".

* 2.2.3 "What is not addressed... (about pre-emption)" contradicts 2.3 
which admits that of these approaches, PCN at least does address pre-emption.

* In section 3, I assume you mean to cross-ref section 2.3, given 2.3.5.2 
doesn't exist.

* 4. ...requests IANA [the -> to] assign

Bob

At 12:33 22/11/2006, Magnus Westerlund wrote:
>Traffic (draft-baker-tsvwg-admitted-voice-dscp) as WG item. Please provide 
>any input both positive and negative at the latest on Wednesday the 6th of 
>December.
>
>Cheers
>
>Magnus Westerlund
>

____________________________________________________________________________
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