Subject: [Tsvwg] comments on: draft-ietf-tsvwg-mlpp-that-works-01

From: ken carlberg <[email-masked]>
Date: Fri, 19 Aug 2005 10:52:09 -0400

James and Fred,

here are some comments on your draft.  I didn't cross check carefully  
if these had been raised by previous posters, so my apologies for any  
duplicates.

Section 1, 1’st para:  just a suggestion, but perhaps you could cite  
T1.619 as motivation for your work and then perhaps cite the work-in- 
progress Pierce documents ([I-D.pierce-ieprep-assured-service-arch]  
and [I-D.pierce-ieprep-assured-service-req]), as additional  
requirements to consider when attempting to support MLPP in IP networks.

The Pierce documents point predominantly at T1.619 as well as other  
documents, but my concern about the Pierce document is that they are  
a work-in-progress, and my personal view is that it would be more  
desirable to point to something more stable with respect to being  
published.  (note: this is not a critique against the Pierce  
documents, but just a desire to stay clear of an initial dependency  
of a work-in-progress – regardless of how little they may have  
changed over the years)

Section 1.1:  Flash Override Override has also been reffered to as  
Critic/ECP (short for Critical / Emergency Call Planning), which is  
referenced in rfc-795.  It may be helpful to mention this as a sidenote.

Section 1.2, second sentence.  Its waaaay to long, making it quite  
hard to parse.  It would be best to break up into two or more  
sentences and clarify why you meant to say.  Questions that arise  
from that one sentence are:
- Are the feedback loops to the caller (ie, person) or the calling  
device?
- When you say “other networks” are you talking in the context of the  
PSTN,
     IP networks, or both?  I get slightly confused on what context  
the section is
     talking about because you start off with a discussion of the  
PSTN, though
     I suspect that the section is on the general topic of call  
admission.
- Could you expand on or define what is “guard band” for those  
uninitiated with that term?

Section 1.3 second para:  I believe an argument about lack of mult- 
homing by the majority of access networks also adds to the  
susceptibility of offered load exceeding available capacity on access  
links.  A good portion of stub networks with single access links have  
2:1 (or more) capacity to offered load ratio, but it is an inability  
to load share via multi-homed links that contributes to congestion at  
those single points that is problematic.

In reading the rest of the draft, it seems that a discussion on the  
topic of administrative authority and/or SLAs is missing in this  
section that is titled “Assumptions about the Network”.  Given that  
part of your solution space covers the use of EF, it would seem that  
the target network supporting MLPP would need to be under a single  
administrative authority (in your example, DoD or more specifically  
DISN operators).  Or a case where a federation of stub networks that  
have SLAs with their transit providers supporting the use/retention  
of DSCP maked packets.  The reason I bring this up is that Sprint has  
(or had, if my info is outdated) a policy of zero’ing out the DSCP  
field of ingress packets if they were marked with anything other than  
best effort.

Section 1.4, 3’rd para:  I would add a qualifier in the first  
sentence stating “Interactive voice and video systems using UDP do  
not tune their behavior to that of the network.”
  The DCCP work with TRFC (and Sally Floyd’s work on a Voice model)  
would now add a more adaptive underlying transport layer to voice.   
Also, some streaming and audio video uses TCP, which would add an  
adaptive component to the flows.

Section 1.4, 4’th para:  very small nit, but in the third sentence  
you could consider saying “…sustained non-negligible loss…”.  FEC  
above the link layer can help repair some non-negligible, but in the  
end we may simply have a difference in semantics.

Section 1.4, 5’th para:  again, you may want to bring up FEC as  
another way for compensating for loss.  Plenty of products are  
offering it at the application layer for voice.

Section 2.1, 2’nd para:  small nit, but you may want to cite  
rfc-3689, where it discusses the role of labels and policy in the  
context of emergency type communication systems.

Section 2.1, 4’th para:  the reference you cite, [I-D.ietf-sip- 
resource-priority] no longer uses “strict” or “loose” modes, so this  
will need to be removed.  This also would make the case that perhaps  
this MLPP document would need to be held up until the SIP R-P header  
document has progressed through the IESG.

Section 2.1, 5’th para:  the word “user” should probably be “use”

Section 2.2, 4’th para: The 3’rd sentence starts off with “Between  
these two,….”, which begs the question, which two?  It was clear  
exactly what you were referring to.

Section 2.3, 2’nd para:  In the second sentence, would it be better  
to qualify the SIP proxy as one that is stateful? A stateless proxy  
would not seem to be a candidate for keeping track of the number of  
calls.

In the fourth sentence of that same paragraph, you mention the  
problem of a single point of failure with the Gatekeeper.  There are  
products offering Gatekeeper-to-Gatekeeper redundancy that I believe  
addresses this issue.  Or were you speaking of an ITU standard that  
addresses this matter?  (I don’t have all the related ITU standards  
on hand, so I can’t answer that).

Section 2.3, 3’rd para: you may want to qualify the last sentence of  
the paragraph to say “…Capacity Admission based on bandwidth is not  
integrated with H.323”.  There is a product that does (well,  
advertises) Capacity Admission based on call counts.  And the pointg  
I believe you wanted to make in the section was CA in terms of  
bandwidth.

Section 2.3.2, last sentence:  when you speak of type 1 encrypted  
interfaces “limited in bandwidth”, at what layer were you speaking  
of, IP?  There are vendors that support Fastlane in layer 2 at 10 Gbs.

I didn’t look at the appendix

One final comments to consider.  With respect to policies, you point  
the reader to rfc-2753, “A Framework for Policy-based Admission  
Control”.  However, there is no mention of rfc-2748 (COPS) or  
rfc-2749 (COPS usage for RSVP).  Now this may be due to rfc-3535 (the  
IAB network Management workshop) that came to the conclusion that  
COPS should be placed as historic for various reasons.  So I’m  
curious as to the MLPP author’s opinion on this topic.  Will you  
resurrect COPS, go for COPSv2(?), or something else?

cheers,

-ken

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Fred Baker <[email-masked]>
Date: Fri, 19 Aug 2005 14:12:18 -0700

THanks for this. I was about to post a new draft collecting inputs  
from Mike, James, and Benny, and I have updated this in as well.  
Please take a look at

     ftp://ftpeng.cisco.com/fred/tsvwg/mlpp-that-works-diff.txt
     ftp://ftpeng.cisco.com/fred/tsvwg/mlpp-that-works.html
     ftp://ftpeng.cisco.com/fred/tsvwg/mlpp-that-works.txt
     ftp://ftpeng.cisco.com/fred/tsvwg/mlpp-that-works.unpg
     ftp://ftpeng.cisco.com/fred/tsvwg/mlpp-that-works.xml

The -diff file is between a depaginated version of the posted draft  
and an unpaginated version of the update. That helps by not confusing  
the reader with things changing from one page to the next.

I'll give folks the weekend to comment, and (from Taiwan) pick up any  
comments that come in by Monday evening Pacific. Tuesday morning,  
I'll ask the secretariat to post this as the new draft, and we can  
continue last call based on that.

Let me make a few notes in-line

On Aug 19, 2005, at 7:52 AM, ken carlberg wrote:

> - When you say “other networks” are you talking in the context of  
> the PSTN,

I have changed that text to read:

Traditionally, in the PSTN, Call Admission Control (CAC) has had the  
responsibility of determining whether a caller has permission (e.g.,  
is an identified subscriber, with identify attested to by appropriate  
credentials) to use an available circuit. IEPS, or any emergency  
telephone service, has additional options that it may employ to  
improve the probability of call completion:

     - The call may be authorized to use other networks that it would  
not normally use</t
     - The network may preempt other calls to free bandwidth,</t
     - The network may hold the call and place it when other calls  
complete, or</t
     - The network may use different bandwidth availability  
thresholds than are used for other calls.</t

At the completion of CAC, however, the caller either has a circuit  
that he or she is authorized to use, or has no circuit. Since the act  
of preemption or consideration of alternative bandwidth sources is  
part and parcel of the problem of providing bandwidth, the  
authorization step in bandwidth provision also affects the choice of  
networks that may be authorized to be considered. The three cannot be  
separated. The CAC procedure finds available bandwidth that the  
caller is authorized to use and preemption may in some networks be  
part of making that happen.</ns:clipboard

Does that work for you?

> susceptibility of offered load exceeding available capacity on  
> access links.  A good portion of stub networks with single access  
> links have 2:1 (or more) capacity to offered load ratio, but it is  
> an inability to load share via multi-homed links that contributes  
> to congestion at those single points that is problematic.

I'm not sure I agree here. Multi-homing generally provides a failure  
path, and it increases total bandwidth available to a network.  
However, it doesn't necessarily increase bandwidth from that network  
to a given destination, because BGP routing results in one next hop  
as opposed to a multipath route.

> part of your solution space covers the use of EF, it would seem  
> that the target network supporting MLPP would need to be under a  
> single administrative authority (in your example, DoD or more  
> specifically DISN operators).  Or a case where a federation of stub  
> networks that have SLAs with their transit providers supporting the  
> use/retention of DSCP maked packets.  The reason I bring this up is  
> that Sprint has (or had, if my info is outdated) a policy of  
> zero’ing out the DSCP field of ingress packets if they were marked  
> with anything other than best effort.

Some networks do that, and a GETS implementation in civilian networks  
would certainly want to have a policy of changing the DSCP if it  
specified the use of some emergency services specific class and  
wasn't authorized to use it. I think the deployment of an emergency  
services class (any such class) requires *some* change to ingress  
DSCP handling, so I'm not sure what the purpose of limiting ourselves  
to services that ignore the DSCP would be.

> adaptive component to the flows.

With all due (very high) respect to Sally, she and I differ on the  
real value of DCCP in a network in which bandwidth is not vastly  
overprovisioned. It's not obvious to me that running an inelastic  
application over an elastic transport turns the application into an  
elastic one. For example, let's say we're using a G.711 codec without  
VAD (codec sends and expects 64 KBPS come hell or high water). If I  
tell you that the rate available to the codec will now vary between  
55 and 70 KBPS over a period of time, what is the implication for the  
codec? Will it now become a variable rate codec? Or will it simply  
perceive substandard service from the network? I think the latter.

> above the link layer can help repair some non-negligible, but in  
> the end we may simply have a difference in semantics.

I think we may have a conceptual difference here. Yes, there are  
various protection codlings that can be used, such as as re-encoding  
a sample in a far more compressed way and carrying that in the packet  
before and/or after the actual sample, so that the loss of a single  
packet doesn't as badly garble a sound. What that does is manage the  
loss of an isolated packet. If I'm losing 5% of the packets in a  
voice stream, every codec I have looked at, even with protection  
coding, and including variable rate codecs like G.723, experiences  
serious loss in sound or picture quality. These happen regardless of  
the authorization level of the call or who is using it.

At the point where a service is trying to preempt a call, queue it,  
or whatever, we are differentiating between some users and others,  
and have already accomplished what protection coding, codec changes,  
or other mitigation techniques can accomplish. At this point, we are  
deciding that something has to go, and considering what  
administrative differences among users might exist.

> offering it at the application layer for voice.

Understood, but ditto. FEC applies to all calls, not separately to  
emergency calls.

> context of emergency type communication systems.

OK

> resource-priority] no longer uses “strict” or “loose” modes, so  
> this will need to be removed.  This also would make the case that  
> perhaps this MLPP document would need to be held up until the SIP R- 
> P header document has progressed through the IESG.

Well, one could hope that the RP header would be expeditiously passed  
by the IESG. While text in the document has been manicured to death,  
the fundamental proposal has not changed int eh past five years, and  
is implemented in several SIP implementations.

> Section 2.1, 5’th para:  the word “user” should probably be “use”

ok

> exactly what you were referring to.

I'm glad it was clear :^)

Does this work?

The real time voice/video application should be generating traffic at  
a rate appropriate to its content and codec, which is either a  
constant bit rate stream or a stream whose rate is variable within a  
specified range. The first hop router should be policing traffic  
originated by the application, as is performed in traditional virtual  
circuit networks like Frame Relay and ATM. Between these two checks  
(at what some networks call the DTE and DCE), the application traffic  
should be guaranteed to be within acceptable limits. As such, given  
bandwidth-aware call admission control, there should be minimal  
actual loss. The cases where loss would occur include cases where  
routing has recently changed and CAC has not caught up, or cases  
where statistical thresholds are in use in CAC and the data streams  
happen to coincide at their peak rates.

> would not seem to be a candidate for keeping track of the number of  

ok

> problem of a single point of failure with the Gatekeeper.  There  
> are products offering Gatekeeper-to-Gatekeeper redundancy that I  
> believe addresses this issue.  Or were you speaking of an ITU  
> standard that addresses this matter?  (I don’t have all the related  
> ITU standards on hand, so I can’t answer that).

The reason that this functionality exists is to deal with the fact  
that a gatekeeper as specified is a single point of failure; these  
products distribute the function to limit the probability of failure.

That said, while the gatekeeper is itself a single point of failure,  
the paragraph refers to the network component it does its  
calculations around as a single point of failure.

I'll split the difference with you. How about this text?

An approach that is commonly used in H.323 networks is to limit the  
number of calls simultaneously accepted by the gatekeeper. SIP  
networks do something similar when they place a stateflu SIP proxy  
near a single ingress/egress to the network. This is able to impose  
an upper bound on the total number of calls in the network or the  
total number of calls crossing the significant link. However, the  
gatekeeper has no knowledge of routing, so the engineering must be  
very conservative, and usually presumes a single ingress/egress or  
the failure of one of its data paths. While this may serve as a short  
term work-around, it is not a general solution that is readily  
deployed. This limits the options in network design.

> Section 2.3, 3’rd para: you may want to qualify the last sentence  
> of the paragraph to say “…Capacity Admission based on bandwidth is  
> not integrated with H.323”.  There is a product that does (well,  
> advertises) Capacity Admission based on call counts.  And the  
> pointg I believe you wanted to make in the section was CA in terms  
> of bandwidth.

How about:

While call counting is specified in H.323, network capacity ddmission  
is not integrated with H.323 at this time.

> of, IP?  There are vendors that support Fastlane in layer 2 at 10 Gbs.

I removed that last clause.

> One final comments to consider.  With respect to policies, you  
> point the reader to rfc-2753, “A Framework for Policy-based  
> Admission Control”.  However, there is no mention of rfc-2748  
> (COPS) or rfc-2749 (COPS usage for RSVP).  Now this may be due to  
> rfc-3535 (the IAB network Management workshop) that came to the  
> conclusion that COPS should be placed as historic for various  
> reasons.  So I’m curious as to the MLPP author’s opinion on this  
> topic.  Will you resurrect COPS, go for COPSv2(?), or something else?

The framework posits COPS as a means to control policy, but does not  
require it. One option in that framework is the existence of a local  
PDP.
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: ken carlberg <[email-masked]>
Date: Sat, 20 Aug 2005 19:36:18 -0400

> Traditionally, in the PSTN, Call Admission Control (CAC) has had  
> the responsibility of determining whether a caller has permission  
> (e.g., is an identified subscriber, with identify attested to by  
> appropriate credentials) to use an available circuit. IEPS, or any  
> emergency telephone service, has additional options that it may  
> employ to improve the probability of call completion:
>
>     - The call may be authorized to use other networks that it  
> would not normally use</t
> that he or she is authorized to use, or has no circuit. Since the  
> act of preemption or consideration of alternative bandwidth sources  
> is part and parcel of the problem of providing bandwidth, the  
> authorization step in bandwidth provision also affects the choice  
> of networks that may be authorized to be considered. The three  
> cannot be separated. The CAC procedure finds available bandwidth  
> that the caller is authorized to use and preemption may in some  
> networks be part of making that happen.</ns:clipboard
>
>
> Does that work for you?

yup, works for me.

> I'm not sure I agree here. Multi-homing generally provides a  
> failure path, and it increases total bandwidth available to a  
> network. However, it doesn't necessarily increase bandwidth from  
> that network to a given destination, because BGP routing results in  
> one next hop as opposed to a multipath route.

true, by default BGP is just going to provide a single route, but  
vendors offer load sharing techniques where multiple equal cost links  
exist between Autonomous Systems.  and some ISPs have offered this to  
its stub clients, with different charging and usage models on the non- 
primary link.  in my eyes, this was not a big issue, just some food  
for thought given your original text.

>> In reading the rest of the draft, it seems that a discussion on  
>> the topic of administrative authority and/or SLAs is missing in  
>> this section that is titled “Assumptions about the Network”.   
>> Given that part of your solution space covers the use of EF, it  
>> would seem that the target network supporting MLPP would need to  
>> be under a single administrative authority (in your example, DoD  
>> or more specifically DISN operators).  Or a case where a  
>> federation of stub networks that have SLAs with their transit  
>> providers supporting the use/retention of DSCP maked packets.  The  
>> reason I bring this up is that Sprint has (or had, if my info is  
>> outdated) a policy of zero’ing out the DSCP field of ingress  
>> packets if they were marked with anything other than best effort.
>>
>
> Some networks do that, and a GETS implementation in civilian  
> networks would certainly want to have a policy of changing the DSCP  
> if it specified the use of some emergency services specific class  
> and wasn't authorized to use it. I think the deployment of an  
> emergency services class (any such class) requires *some* change to  
> ingress DSCP handling, so I'm not sure what the purpose of limiting  
> ourselves to services that ignore the DSCP would be.

actually, we are in agreement with what you just said.  my original  
comment stemmed from my perhaps mistaken perception that your  
proposed approach to support MLPP assumed EF end-to-end through  
contiguous diff-serv domains.  with GETS, there have been discussions  
of deploying DSCP where feasible/possible, but not relying an end-to- 
end contiguous model.

>> would now add a more adaptive underlying transport layer to  
>> voice.  Also, some streaming and audio video uses TCP, which would  
>> add an adaptive component to the flows.
>
> elastic one. For example, let's say we're using a G.711 codec  
> without VAD (codec sends and expects 64 KBPS come hell or high  
> water). If I tell you that the rate available to the codec will now  
> vary between 55 and 70 KBPS over a period of time, what is the  
> implication for the codec? Will it now become a variable rate  
> codec? Or will it simply perceive substandard service from the  
> network? I think the latter.

yes, good points.  I had in mind the potential that DCCP can offer  
now that it exists, and that over time new codecs with an elastic  
component would be deployed.  but I can understand a reticence in  
planning for the potential versus what exists.

> various protection codlings that can be used, such as as re- 
> encoding a sample in a far more compressed way and carrying that in  
> the packet before and/or after the actual sample, so that the loss  
> of a single packet doesn't as badly garble a sound. What that does  
> is manage the loss of an isolated packet. If I'm losing 5% of the  
> packets in a voice stream, every codec I have looked at, even with  
> protection coding, and including variable rate codecs like G.723,  
> experiences serious loss in sound or picture quality. These happen  
> regardless of the authorization level of the call or who is using it.
>
> and have already accomplished what protection coding, codec  
> changes, or other mitigation techniques can accomplish. At this  
> point, we are deciding that something has to go, and considering  
> what administrative differences among users might exist.

yes, we are in agreement, and actually, I think you took my text  
beyond what I had intended.  the point i wanted to make was that  
techniques like FEC, redundant packets, or even inter-leaving can  
generally compensate well for occasional periodic and bursty loss.   
but that *sustained* loss over extended periods of time is still  
problematic for these techniques.

> Understood, but ditto. FEC applies to all calls, not separately to  

agreed.

>> perhaps this MLPP document would need to be held up until the SIP  
>> R-P header document has progressed through the IESG.
>>
>
> Well, one could hope that the RP header would be expeditiously  
> passed by the IESG. While text in the document has been manicured  
> to death, the fundamental proposal has not changed int eh past five  
> years, and is implemented in several SIP implementations.

quite agree.

> Does this work?
>
> The real time voice/video application should be generating traffic  
> at a rate appropriate to its content and codec, which is either a  
> constant bit rate stream or a stream whose rate is variable within  
> a specified range. The first hop router should be policing traffic  
> originated by the application, as is performed in traditional  
> virtual circuit networks like Frame Relay and ATM. Between these  
> two checks (at what some networks call the DTE and DCE), the  
> application traffic should be guaranteed to be within acceptable  
> limits. As such, given bandwidth-aware call admission control,  
> there should be minimal actual loss. The cases where loss would  
> occur include cases where routing has recently changed and CAC has  
> not caught up, or cases where statistical thresholds are in use in  
> CAC and the data streams happen to coincide at their peak rates.

works for me

> That said, while the gatekeeper is itself a single point of  
> failure, the paragraph refers to the network component it does its  
> the failure of one of its data paths. While this may serve as a  
> short term work-around, it is not a general solution that is  
> readily deployed. This limits the options in network design.

works for me

> How about:
>
> While call counting is specified in H.323, network capacity  
> ddmission is not integrated with H.323 at this time.

okey dokey

> The framework posits COPS as a means to control policy, but does  
> not require it. One option in that framework is the existence of a  
> local PDP.

ok.  it might be helpful to add the above just for added clarification.

cheers,

-ken