Subject: Re: [Tsvwg] EF-ADMIT & PCN DSCP(s)

From: Fred Baker <[email-masked]>
Date: Thu, 13 Mar 2008 08:25:29 -0400

oops, resending - I include "tsvwg-chairs" on the CC line instead of  
"tsvwg".

On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote:
> Finally, I just read thru Capacity Admitted Traffic -04. I've got  
> quite a few comments, so I'll write them up tomorrow and post to  
> tsvwg. Next mail I'll also re-send the briefer review comments I  
> sent on it just under a year ago, which didn't seem to get noticed.

Hmm. Yes, please send your comments.

2006-2008, I see 18 notes that comment on draft-ietf-tsvwg-admitted- 
realtime-dscp. Four of them announce the posting of a draft. One is  
the posting of minutes to a meeting in which a draft was discussed.

Two are Magnus' comments of 13 February, addressed in draft -04, and  
four others are chitchat on 24 Feb pursuant to that. One is Martin  
Dolly agreeing to a set of changes. Brian Carpenter doesn't  
understand why we mention rate policing, as it is mentioned in RFC  
3246. Janet Gunn would like draft-ietf-tsvwg-emergency-rsvp to refer  
to this draft (March 28 2007), which Ken Carlberg also commented on.  
One comment is from Dave McDysan, essentially asking that Video be  
added to the original Voice considerations.

On March 21 March 2007, the email the quoted this morning, you  
suggested that we go for a second code point for video.

> So here's a proposal:
> - two DSCPs from IANA for EF-admit-voice and EF-admit-video
> - of which an operator can choose to use one (probably the voice  
> one) as just EF-admit-* if they want
>
> Is that feasible? Or have I missed the point?

This is something we looked at when you originally asked, and wound  
up deciding (in -03 and -04) to simply apply the considerations to  
existing video classes in 4594 rather than trying to allocate classes  
willy-nilly. As to your suggestion of dumping voice and video  
together in a common class and telling the operator to pick one of  
two DSCPs depending on admission or non-admission, the matter is  
discussed in RFCs 4594 and 5127. On gigabit links (the RFC 5127 case,  
the one PCN is applicable on), fine. On lower speed links (as a rule  
of thumb, below ten megabit), the interaction between voice and video  
traffic in the same class is disruptive to voice, and PCN is  
inapplicable because the process of adding a single data flow of  
speed at the same order of magnitude as the link rate is disruptive  
to the existing traffic. Lower speed access links being the primary  
consideration of RFC 4594 and of draft-ietf-tsvwg-admitted-realtime- 
dscp, I don't see the sense in befuddling the document with  
suggestions only applicable to gigabit links. That was the upshot of  
our discussion at the time and later in London at the IET as I  
recall. In my mind, this has been asked and answered.

Bringing forward the private discussion you and I had overnight:

On Mar 13, 2008, at 2:53 AM, Bob Briscoe wrote:
> Fred,
>
> Tx for this. Some mark-up of your proposed text below (in HTML)...
>
> At 21:50 12/03/2008, Fred Baker wrote:
>> Bob and Anna:
>>
>> Following up on our chat today.
>>
>> So I think we agreed to do something like the following. I need
>> pointers to currently-relevant drafts and any other text changes that
>> you would like to see. We spoke about adding a paragraph which I
>> envision something like this. Please edit and correct.
>
> Are you meaning this to replace S.2.2.3 or add to it? Given Kwok &  
> Georgios supplied that text originally, I've cc'd them. I suggest  
> this new text goes beneath the text on Distributed approaches,  
> because PCN is also distributed and is another way to address  
> scalability of the big numbers region, other than RSVP aggregation.

I was thinking of something in the *recommendation*, which is section  
3. I'll have to think about exactly how to organize it in. What I  
sent you was the substance of a sub-paragraph that I proposed to add.

> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
>> n.n.n Use of PCN signaling in a Diffserv domain
>>
>> [RFC2998] describes the integration of an Integrated Services domain
>> such as described in this document with a Differentiated Services
>> domain such as the relatively high speed links used in the Internet
>> core. Figure N depicts such a mixture of domains. Host H1 is in an
>> integrated services domain such as a SOHO connected via a relatively
>> low uplink rate access link. It places a "call" to Host H2, which is
>> in another Intserv domain. These pass through some number of routers
>> that implement the Integrated Services model on the relevant
>> interfaces, labeled IR1 through IR4. In the Differentiated Services
>> domain, the routers are configured to use PCN to detect and report
>> precongestion events.
>
> [draft-ietf-pcn-architecture]
>
>
>>       ,---.                ,-------.                ,---.
>>     ,'     `.            ,'         `.            ,'     `.
>>   ,' Intserv `.        ,'  Diffserv/  `.        ,' Intserv `.
>>  ;   Domain    :      /    PCN Domain   \      ;   Domain    :
>>  ;             :     /       +---+       \     ;             :
>> ;+--+   +---+   :---;        +DR2+        :---;   +---+   +--+:
>> ||H1+---+IR1+---+IR2.      .'+---+`.     .'IR3+---+IR4+---+H2||
>> :+--+   +---+   ;---:`. +-+-+     +-+-+ / ;---:   +---+   +--+;
>>  :             ;     \ `+DR1|     |DR3+' /     :             ;
>>  :             ;      \ +---+     +---+ /      :             ;
>>   `.         ,'        `.             ,'        `.         ,'
>>     `.     ,'            `.         ,'            `.     ,'
>>       `---'                `-------'                `---'
>> Figure N
>> Integration of Integrated Services with Differentiated Services
>>
>> In such a scenario, one would expect that, as described in [RFC2998],
>> the routers DR1 through DR3 do not implement Integrated Services.
>> Rather, one expects that routers IR2 and IR3 serve as edge routers
>> between the Diffserv and Intserv domains, and must translate the
>> signaling. In essence, if IR3 receives an new request to place a
>> reservation and is seeing precongestive signaling,
>
> more than a threshold level of pre-congestion notification (PCN),
>
>> it should refuse the request, unless there is a relevant policy  
>> permitting a specified requester to be exempt from that behavior.
>
>> The danger in such a scenario is that the combined behavior of
>> variable rate codecs might permit a "call" to be placed at one time
>> and for those "calls" to then create serious congestion at another
>> time. The parameters for managing such scenarios, as well as the
>> specific algorithms related to PCN for these services classes, is
>> discussed in [XXX].

Your reply used an html format and crossed out the words  
"precongestive signaling" and the text following "refuse the  
request". I think Janet Gunn would likely want the rest of that  
sentence to remain, as it allows her to build her favorite service,  
but that is perhaps a nit. I return this to standard SMTP text  
formatting to make the picture readable :-)

> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
> I've scrubbed stuff about policy-based AC because you've said "in  
> essence", so there's no need to add detail describing policy  
> behaviours here, which could contradict stuff written in the PCN  
> docs now or later.

I'm not trying to worry about the PCN docs. I'm noting that there  
might be interesting policy issues.

> Incidentally, variable rate codecs that have made a signalled  
> reservation shouldn't increase their rate without modifying their  
> reservation, but they can reduce their rate to a lower bit-rate  
> codec without modifying their reservation. So I've scrubbed your  
> para about this, because it seems like too much detail for your  
> draft which isn't really about PCN, and it's a non-danger anyway.

Yes, but the proposed text isn't talking about that. It is talking  
about the effect of variable rate codecs on measurement-based  
admission schemes in which correlated behavior occurs. Examples  
include last week's 242 GBPS phone call by Oprah (http:// 
www.disruptivetelephony.com/2008/03/the-oprah-tizat.html) or the  
behavior of TV advertisements (since TV channels know that users  
channel surf during ads, they correlate the times at which they  
advertise in order to catch eyeballs, which means that TV/DSL tends  
to have significant correlated traffic bursts around advertising).

> Finally, I just read thru Capacity Admitted Traffic -04. I've got  
> quite a few comments, so I'll write them up tomorrow and post to  
> tsvwg. Next mail I'll also re-send the briefer review comments I  
> sent on it just under a year ago, which didn't seem to get noticed.

As I say, I think I actually went through them, and found them to  
mostly be applying gigabit link considerations on sub-megabit upload- 
rate links. But I am very interested to catch your relevant comments.

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 13 Mar 2008 19:02:21 -0400

I am having some difficulty following this email, as there was apparently 
some html "markup" which has been lost.

Please explain which sentence has been "crossed out"  which would affect 
my "favorite service".  Is it a sentence currently in -04, or in proposed 
additional text.

Are you trying to say that pcn would constitute  an alternative to RSVP as 
meeting the criteria "admitted".  If so, what is the mechanism for 
considering RPH in admission criteria for pcn? (For RSVP, we have 
draft-ietf-tsvwg-emergency-rsvp-05)

Are you proposing changes to this text in section  2.3?
"If capacity admission as described in Section 2.2.3 is in use, then
   multiple thresholds must be applied in marking the traffic, multiple
   traffic marks must be applied, or there must be multiple ways to
   interpret the result.  In any event, this is only applicable in
   domains in which the law of large numbers applies."

Janet 

Computer Sciences Corporation 
Registered Office: 2100 East Grand Avenue, El Segundo California 90245, 
USA
Registered in USA No: C-489-59

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------