Subject: Re: [PWE3] [Fwd: Guidelines for protocol designers using UDP]

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Oct 2007 14:30:09 +0200

Yaakov Stein skrev:
>  
>> We specify TDM over UDP and so should look at this.
> 
>> Yaakov - is this something that we should request be liaised to SG13?
> 
> Stewart, 
> 
> This document is certainly interesting, but does not directly address
> our kind of application.
> 
> When sending TDM over UDP/IP the rate CAN NOT be reduced without
> serious service disruption, but on the other hand, the service
> DOES NOT increase in bandwidth over time, nor does it have 
> momentary peaks of high bandwidth usage.
> 
> Thus the recommendations are mostly irrelevant
> (there is no way of backing off the rate except disrupting the service)
> but the impact is not serious (since the TDM over UDP/IP will
> not increase in rate to capture the bandwidth given up by 
> falling back TCP flows).
> 

I don't think it is a irrelevant at all. TDM over UDP is a very
difficult problem when it comes to congestion control that we need to
continue to discuss and find a solution for. So we definitely appreciate
to get feedback on the document from your view point.

I am concerned that you think that application with limitation is
sufficient to mitigate the need for proper congestion control. There are
still a lot of cases in a general best effort network when TDMA can
create havoc. For example if the fair share is magnitudes less than what
the TDMA uses, then bringing a TDMA pseudowire up or failing to removing
it would be very bad.

> Perhaps we should liaise the TSVWG first ...

Liaise is maybe going to far. But talking to TSVWG directly can
definitely be done. I would like to understand the benefits SG 13 could
have and what feedback we could get. However, waiting for a revision is
probably a good thing.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 2 Oct 2007 16:43:51 +0200

Magnus

I believe that "difficult" is an understatement. Perhaps "impossible" is
a better term.
For the TDM case, unless special mechanisms are employed 
nothing short of withdrawal of the PW is a true solution.
Since that is not a good solution, I am not sure how fruitful our
feedback can be.

Special mechanisms can exist for structure-aware TDM carrying telephony.
In such cases there are options. 
For example, fallback from AAL1 to AAL2 mode and use of silence
suppression,
or selective termination of individual calls, or not allowing new calls
to come up.

At the last IETF meeting there was a lunch meeting on PWE congestion.
The question raised there was the meaning of fairness.
If a TDM PW serving 100 customers is impacting TCP/IP flows from 10
customers,
what is the "fair" thing to do ?

Should the TDM PW be considered a single flow, and required to
relinquish
X bits per second of BW or be killed ?

Should it be considered 100 aggregated flows and thus worth 100 times
more ?

The way it is supposed to work is to CAC so that you don't bring up a
TDM PW
unless there is sufficient BW. 

Given that assumption, TDM PWs are relatively well behaved, as they are
not greedy.

The problem with that is what happens after a reroute event, when a TDM
PW
that was brought up in an environment with sufficient BW, finds itself
in one without.

Once again, the only viable option (assuming not special cases) is to
withdraw the PW.

> Liaise is maybe going to far. 

I was being facetious when I used that terminology.

At the last IETF meeting Luca said that he was working on a PW
congestion solution draft
to complement the requirements draft.
I offered to help with the TDM section, and that offer still stands.

Y(J)S

---

From: <[email-masked]>
Date: Tue, 2 Oct 2007 16:27:35 +0100

I agree with what Yaakov says below.  And the key point is that when you
transport 'TDM' ..which is a higher layer network and *not* a single
end-system application...it can be composed of a large number of
end-system applications.  Moreover, I don't believe it makes sense to
try and classify a higher layer network client as either message (UDP),
file (TCP) or stream (RTP) in nature as we are usually dealing with an
aggregate of these which will not necessarily have a consistent mix (ie
they could be a time variable mix).  This is also why PDH and SDH layer
networks per se do not have end-system application adaptation functions.
I also refer you to my earlier posting on this topic where I discuss
this matter in a little more detail, and in particular express my
opinion that we should not be using end-system adaptation functions to
carry a higher layer network client anyway (sent Thu 27/9/2007 14:04).

regards, Neil

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]] 
> Sent: 02 October 2007 15:44
> To: Magnus Westerlund
> Cc: pwe3; [email-masked]
> Subject: RE: [PWE3] [Fwd: Guidelines for protocol designers using UDP]
> 
> 
> Magnus
> 
> difficult problem when it comes to congestion control that we 
> need to continue to discuss and find a solution for. So we 
> definitely appreciate to get feedback on the document from 
> your view point.
> 
> I believe that "difficult" is an understatement. Perhaps 
> "impossible" is a better term. For the TDM case, unless 
> special mechanisms are employed 
> Since that is not a good solution, I am not sure how fruitful 
> our feedback can be.
> 
> Special mechanisms can exist for structure-aware TDM carrying 
> telephony. In such cases there are options. 
> For example, fallback from AAL1 to AAL2 mode and use of 
> silence suppression, or selective termination of individual 
> calls, or not allowing new calls to come up.
> 
> At the last IETF meeting there was a lunch meeting on PWE 
> congestion. The question raised there was the meaning of 
> fairness. If a TDM PW serving 100 customers is impacting 
> TCP/IP flows from 10 customers, what is the "fair" thing to do ?
> 
> Should the TDM PW be considered a single flow, and required 
> to relinquish X bits per second of BW or be killed ?
> 
> Should it be considered 100 aggregated flows and thus worth 
> 100 times more ?
> 
> 
> sufficient to mitigate the need for proper congestion 
> control. There are still a lot of cases in a general best 
> effort network when TDMA can create havoc. For example if the 
> fair share is magnitudes less than what the TDMA uses, then 
> bringing a TDMA pseudowire up or failing to removing it would 
> be very bad.
> 
> The way it is supposed to work is to CAC so that you don't 
> bring up a TDM PW unless there is sufficient BW. 
> 
> Given that assumption, TDM PWs are relatively well behaved, 
> as they are not greedy.
> 
> The problem with that is what happens after a reroute event, 
> when a TDM PW that was brought up in an environment with 
> sufficient BW, finds itself in one without.
> 
> Once again, the only viable option (assuming not special 
> cases) is to withdraw the PW.
> 
> 
> At the last IETF meeting Luca said that he was working on a 
> PW congestion solution draft to complement the requirements 
> draft. I offered to help with the TDM section, and that offer 
> still stands.
> 
> Y(J)S
> 
>

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 2 Oct 2007 17:46:07 +0300

Magnus and all,
In general I concur with Yaakov, but I'd like to re-shuffle some of his
statements.

1. The very concept of "fairness" looks problematic when we try to
distribute limited resources (e.g., BW)
    among *fundamentally different* types of consumers:
    - TCP flows that are end-to-end, so that a single flow can be
considered as serving a single user 
    - pseudowire flows that are edge-to-edge and hence can aggregate
traffic from multiple users per flow.
    I do not know what "fairness" means in this case (and IMHO I am not
alone in this regard:-).
    IMHO an even  more interesting use case for understanding the
meaning of "fairness" is provided by L2TPv3 over UDP:
    - multiple PWs can run over a single UDP flow (the demuxing is done
by the L2TPv3 session ID)
    - each PW can aggregate traffic from multiple end users.
2. TDM over UDP is not different in any way from TDM over L2TPv3 or TDM
over MPLS-in-IP/MPLS-in-GRE. 
    In all these cases:
   - the PW can run over the public Internet 
   - the BW consumed by a single flow cannot be reduced unless the flow
is stopped completely
    - on the other hand, the BW consumed by a single flow does not grow
with time, no matter what.
    As a consequence, I am not sure that the congestion control for TDM
PWs should be really limited to UDP flows.

My 2c.

Regards,
                Sasha
-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Tuesday, October 02, 2007 5:44 PM
To: Magnus Westerlund
Cc: pwe3; [email-masked]
Subject: RE: [PWE3] [Fwd: Guidelines for protocol designers using UDP]

Magnus

I believe that "difficult" is an understatement. Perhaps "impossible" is
a better term.
For the TDM case, unless special mechanisms are employed nothing short
of withdrawal of the PW is a true solution.
Since that is not a good solution, I am not sure how fruitful our
feedback can be.

Special mechanisms can exist for structure-aware TDM carrying telephony.
In such cases there are options. 
For example, fallback from AAL1 to AAL2 mode and use of silence
suppression, or selective termination of individual calls, or not
allowing new calls to come up.

At the last IETF meeting there was a lunch meeting on PWE congestion.
The question raised there was the meaning of fairness.
If a TDM PW serving 100 customers is impacting TCP/IP flows from 10
customers, what is the "fair" thing to do ?

Should the TDM PW be considered a single flow, and required to
relinquish X bits per second of BW or be killed ?

The way it is supposed to work is to CAC so that you don't bring up a
TDM PW unless there is sufficient BW. 

The problem with that is what happens after a reroute event, when a TDM
PW that was brought up in an environment with sufficient BW, finds
itself in one without.

At the last IETF meeting Luca said that he was working on a PW
congestion solution draft to complement the requirements draft.
I offered to help with the TDM section, and that offer still stands.

Y(J)S

---

From: <[email-masked]>
Date: Tue, 2 Oct 2007 16:57:08 +0100

Colleagues,

What is the scope of this - is it private IP networks or just public IP
networks (i.e. the Internet), or both?

I may be looking at this too simplistically but my view is:

If it's private IP networks then it's down to the operator & their SLA
with their customer as to what is considered fair, and whether to kill
the TDM PW or let other traffic suffer.  Appropriate mechanisms should
be provided to operators to allow them to kill a PW under congestion.

If it's the Internet then IMO it's just tough if your PW gets killed.
If you want a reliable guaranteed end-to-end service don't run it over a
best effort network.

Ben

Yaakov Stein <mailto:[email-masked]> wrote:
> "impossible" is a better term.
> If a TDM PW serving 100 customers is impacting TCP/IP flows
> from 10 customers, what is the "fair" thing to do ?
> 
> PW congestion solution draft to complement the requirements draft.

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 2 Oct 2007 18:23:48 +0300

Ben and all,
IMHO you de-facto re-phrase what Section 8 "Congestion Control" in RFC
4553 says:

<quote>
8.  Congestion Control

   As explained in [RFC3985], the PSN carrying the PW may be subject to
   congestion.  SAToP PWs represent inelastic constant bit-rate (CBR)
   flows and cannot respond to congestion in a TCP-friendly manner
   prescribed by [RFC2914], although the percentage of total bandwidth
   they consume remains constant.

   Unless appropriate precautions are taken, undiminished demand of
   bandwidth by SAToP PWs can contribute to network congestion that may
   impact network control protocols.

   Whenever possible, SAToP PWs SHOULD be carried across traffic-
   engineered PSNs that provide either bandwidth reservation and
   admission control or forwarding prioritization and boundary traffic
   conditioning mechanisms.  IntServ-enabled domains supporting
   Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains
   [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide
   examples of such PSNs.  Such mechanisms will negate, to some degree,
   the effect of the SAToP PWs on the neighboring streams.  In order to
   facilitate boundary traffic conditioning of SAToP traffic over IP
   PSNs, the SAToP IP packets SHOULD NOT use the DiffServ Code Point
   (DSCP) value reserved for the Default Per-Hop Behavior (PHB)
   [RFC2474].

   If SAToP PWs run over a PSN providing best-effort service, they
   SHOULD monitor packet loss in order to detect "severe congestion".
   If such a condition is detected, a SAToP PW SHOULD shut down bi-
   directionally for some period of time as described in Section 6.5 of
   [RFC3985].
<end quote>
Your phrasing is definitely shorter, though...

Regards,
                Sasha
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Tuesday, October 02, 2007 6:57 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] [Fwd: Guidelines for protocol designers using UDP]

Colleagues,

Ben

Yaakov Stein <mailto:[email-masked]> wrote:
> continue to discuss and find a solution for. So we definitely 
> appreciate to get feedback on the document from your view point.
> 
> I believe that "difficult" is an understatement. Perhaps "impossible" 
> is a better term.

> sufficient to mitigate the need for proper congestion control. There 
> are still a lot of cases in a general best effort network when TDMA 
> can create havoc. For example if the fair share is magnitudes less 
> than what the TDMA uses, then bringing a TDMA pseudowire up or failing

> to removing it would be very bad.
> 
> Given that assumption, TDM PWs are relatively well behaved, as they 
> are not greedy.
> 
> The problem with that is what happens after a reroute event, when a 
> TDM PW that was brought up in an environment with sufficient BW, finds

---

From: [email-masked]
Date: Tue, 2 Oct 2007 20:02:18 -0400

Yaakov,

> bring up a TDM PW unless there is sufficient BW.

In other words, by blasting away at fixed bandwidth, a TDM PW
assumes that someone has "cleared the path" for it.  It needs
to periodically re-check that assumption, just in case:

> The problem with that is what happens after a reroute event, when
> a TDM PW that was brought up in an environment with sufficient BW,
> finds itself in one without.

If the "cleared the path" assumption becomes false, and there is
no admission control or other traffic management mechanism that
can rapidly restore that assumption, and the PW is at risk of
causing damage to other traffic, then:

> Once again, the only viable option (assuming not special cases)
> is to withdraw the PW.

An operator who doesn't like this consequence should have
provisioned better against the failure case that caused it, and
hence the TDM PW shutdown is a consequence of the operator's
network provisioning decisions.  If the pseudo-wire is more
important than all the other traffic it's competing with after
the failure, then the operator needs to have O&M mechanisms in
place to get rid of that other traffic as part of responding
to the failure, as 10 pounds of <bleep> does not fit in a 5
pound sack.  We should not be trying to make up for the
operator's failure to put contingencies in place.

Provided that the TDM PW will shut down if operating in a
regime where it may cause severe damage, then I would
argue (in doing so, I'm speaking as a Transport Directorate
member, but not speaking for the Transport ADs) that the
SHOULD language in Section 3.1 of the UDP guidelines draft
may be bypassable based on some design work:

   If an application or upper-layer protocol chooses not to
   use a congestion-controlled transport protocol, it SHOULD
   control the rate at which it sends UDP messages to a
   destination host, in order to fulfill the requirements
   of [RFC2914].

The important thing is that this is a "SHOULD", not a "MUST".
RFC 2119 defines "SHOULD" as:

   there may exist valid reasons in particular circumstances
   to ignore a particular item, but the full implications
   must be understood and carefully weighed before choosing
   a different course.

IMHO, the pwe3 WG ought to ensure that the full implications are
understood and carefully weighed.  Unfortunately, while RFC 3985
is a good start, it appears to fudge the issue (Section 6.5):

   The comparison to TCP cannot be specified exactly but is
   intended as an "order-of-magnitude" comparison in timescale
   and throughput.

How does one figure out whether an implementation has done that?
There's no ":-)" here - this is a serious question.  The RFC 4553
text that Sasha posted points to RFC 3985, and hence doesn't help.

For the TDM pseudo wire, let me suggest picking up on where
RFC 3985 left off.  RFC 3448 section 3.1 says that the inputs
to the TCP throughput equation are:

   The parameters s (packet size), p (loss event rate) and R (RTT)
   need to be measured or calculated by a TFRC implementation.

For the TDM pseudo-wire, s and p should be determinable from
received traffic, leaving R.  R really SHOULD be measured based
on sampling the actual traffic delays, and for a TDM PW, this
has the added benefit of enabling one to shut down the PW when
the delay exceeds what is reasonable for interactive voice.
I'm not clear on whether this is always possible, though.

Now the receiver can calculate the TFRC sending rate.  A base
TFRC rate is also needed from somewhere - this could be the
provisioned rate of the pseudo-wire, but might better be a rate
based on measurements when the PW and network are known to be
operating normally.  I suggest measurements because a PW does
not react to losses in the same fashion as TCP, and hence the
TFRC rate may not correspond to the PW's provisioned rate in
any meaningful fashion (e.g., I could imagine a voice PW
tolerating losses [manifest as static or silence] that would
bring TCP to its knees).

Next, define a damage threshold - this will involve all sorts
of (hopefully useful) debate about level of damage to other
traffic that is "acceptable."  Suppose the damage threshold is
25% (this is an arbitrary number, I have no idea whether it's
reasonable) - when the calculated TFRC rate for the PW drops
below the base TFRC rate by 25%, something is very wrong, so
shut down the pseudo wire.  RFC 3985 implies that a damage
threshold of 90% is acceptable - I'm not sure about that.

I freely admit to not being a PW expert and not having all the
answers, but there may be a design approach here that leads to
something useful for congestion control of fixed BW pseudo-wires.
More specifics on how a PW should behave in the face of congestion
would be a good thing, as they improve the robustness of
networks onto which PW's "escape" due to reroute events and the
like.  If the problem can be solved for fixed-bandwidth
pseudo-wires, that's a step towards a more general solution.

As for the fairness issue:

> congestion.

For a fixed-bandwidth PW, the question is not one of fairness,
but network survival - have things gotten bad enough that this
PW needs to be shut down for the network to survive?  IMHO,
that question ought to be asked about the PW as a whole, unless
there's a CAC mechanism that can terminate individual flows.
Even so, when the congestion threshold trips, things have gotten
very bad, and so something has to give, dramatically - getting
that to work is more important than optimizing for fairness
(and keep in mind that based on the discussion above, the PW
is in seriously abnormal operating conditions if the congestion
threshold trips).  If there's a CAC that can strip channels,
then when the congestion threshold trips, TCP's behavior suggests
a starting point of dropping half the channels other half survive.  

In all of the above, I'm making up numbers - the 25% threshold
dropping half the calls in particular - real data from
measurements and simulation would be quite useful.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> Sent: Tuesday, October 02, 2007 10:44 AM
> To: Magnus Westerlund
suppression, 
> or selective termination of individual calls, or not allowing 
> new calls to come up.
> 
are
TDM PW
> that was brought up in an environment with sufficient BW,
> finds itself in one without.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Oct 2007 09:55:51 +0200

Hi,

I would start with thanking David for a good email. I think he raises a
lot of important things. I agree with fairness here is very hard to
define. But for TDM PW I do expect that there will be possible to create
a mechanism that prevents TDM PWs to be brought up or stay up in the
face of persistent congestion. As David says, if the operator cares
about the PW he should manage them such that this do not occur and
result in shutdown. If one can go further towards TCP friendly or not
will need some investigation. But I do expect that your work (PWE3 WG)
do look at this.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 3 Oct 2007 10:52:41 +0200

David, 

Thanks for a good summary of the issues 
and concrete suggestions on a way forward.

I will comment on a few of your points.

> It needs to periodically re-check that assumption, just in case ...

The TDMoIP draft provides for UDP an OAM mechanism
that can monitor for congestion based on propagation
delay signatures. We have used this to trigger various
mechanisms to save BW (as I mentioned in my previous email).

(As an aside - I promised the WG not to extend that mechanism for the
MPLS case,
but rather to build on VCCV. This could be accomplished using
Y.1731 PDUs, but unfotunately, draft-mohan-pwe3-vccv-eth
is not getting anywhere due to incorrect perceptions regarding
its relationship to Ethernet as a transport layer. So for MPLS
there is, as yet, no corresponding mechanism.)

Yes, I like the SHOULD in this context.

> The RFC 4553 text that Sasha posted points to RFC 3985, and hence
doesn't help.

But the 4553 text adds a lot more. It talks about bandwidth reservation
and CAC, 
explains how to use with DiffServ, explains that OAM should be run to
monitor
for congestion, and proposes withdrawal to save the network from
collapse
(as SAToP PWs, unlike structure-aware TDMPWs, can not support anything
smarter). 

> R really SHOULD be measured based on sampling the actual traffic
delays, and for a TDM PW, 
this has the added benefit of enabling one to shut down the PW when the
delay exceeds what is reasonable for interactive voice.
I'm not clear on whether this is always possible, though.

As aforementioned, it is possible, and we do it all the time.

>  (e.g., I could imagine a voice PW tolerating losses [manifest as
static or silence] that would bring TCP to its knees).

See my obsolete draft on the effect of packet loss on perceived  voice
quality.
BTW, for certain applications we can use selective dropping of packets
at source, 
with selection to minimize perceived voice degradation.

> 25% (this is an arbitrary number, I have no idea whether it's
reasonable) 

Once again, see my obsolete draft. For random dropping and not
compensation,
the perceived quality drops below usable quality at about 5%.
When using structure aware TDM PWs, much higher percentages are possible
if you are willing to expend the processing power at the egress gateway.
For SAToP, or nonvoice applications, it would seem that even a few
percent
of packet loss degrades the service to the point where it is unusable.

> RFC 3985 implies that a damage threshold of 90% is acceptable 

Can you point out where it says that ?

>  If the problem can be solved for fixed-bandwidth pseudo-wires, that's
a step towards a more general solution.

I think the non-fixed-BW problem is easier, 
and I believe that Luca is going to present something soon.

> For a fixed-bandwidth PW, the question is not one of fairness, but
network survival 

There are two questions, fairness and survival.
For example, the network can survive by killing the PW, or all traffic
other than the PW.

> Even so, when the congestion threshold trips, things have gotten very
bad, and so something has to give, dramatically 

By monitoring delay signatures we can see the congestion coming before
it is really bad.
So let's ask the fairness question at that point.

Y(J)S

---

From: [email-masked]
Date: Wed, 3 Oct 2007 10:11:00 -0400

Yaakov,

> mechanisms to save BW (as I mentioned in my previous email).

Good - increasing RTT is often an early sign of congestion as
the network queues packets before resorting to dropping them.
In this sort of situation, being able to react to the delay
increase may be more effective than waiting for the drops.

> > The RFC 4553 text that Sasha posted points to RFC 3985, and
> > hence doesn't help.
> 
> But the 4553 text adds a lot more.

I agree, but we're talking past each other.  What's missing from
these RFCs is concrete "do this" instructions to an implementer
about how to measure and react to congestion.

reasonable) 
compensation,
> the perceived quality drops below usable quality at about 5%.

These are percentages for different things.  The 25% "damage threshold"
is a TCP throughput ratio on the output of the TCP throughput equation.
The packet drop ratio (the 5%) is an input to this equation.  Needless
to say, the relationship between packet drop rate and TCP throughput
rate is non-linear (see Section 3.1 of RFC 3448 for details).  A 5%
packet drop ratio is definitely sufficient to bring TCP to its knees.

> Can you point out where it says that ?

It's in the Section 6.5 text that I quoted - an "order-of-magnitude"
comparison implies that a 90% throughput difference is acceptable:

Keep in mind that this is a 90% ratio in TCP throughput - it's *not*
90% packet drop!

> > Even so, when the congestion threshold trips, things have 
> gotten very bad, and so something has to give, dramatically 
> 
> it is really bad.  So let's ask the fairness question at that point.

I'm concerned that this "fairness" discussion is going to have
"angels on the head of a pin" characteristics.  Nonetheless, my
line of thinking is that because the individual flows (calls)
are fixed bandwidth and hence non-responsive in a TDM PW, the
congestion measurement and response has to be on the whole PW,
with CAC used to shed calls when things get bad.

I would caution about getting enthusiastic in response to being
able to "see the congestion coming" as call termination is a
fairly dramatic response.  The pcn WG is hard at work on a
mechanism that can also "see the congestion coming", and has
adopted an approach with two thresholds for CAC - when the first
threshold is reached, admission of new calls is blocked, and
only when a second, more severe, threshold is reached is
call termination invoked.

Thanks,
--David

> Sent: Wednesday, October 03, 2007 4:53 AM
> To: Black, David; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> (As an aside - I promised the WG not to extend that mechanism 
> for the MPLS case,
> But the 4553 text adds a lot more. It talks about bandwidth 
> reservation and CAC, 
> explains how to use with DiffServ, explains that OAM should 
> be run to monitor
> for congestion, and proposes withdrawal to save the network 
> from collapse
> (as SAToP PWs, unlike structure-aware TDMPWs, can not support 
> anything smarter). 
> 
> 
> > R really SHOULD be measured based on sampling the actual 
> traffic delays, and for a TDM PW, 
> See my obsolete draft on the effect of packet loss on 
> perceived voice quality.
> BTW, for certain applications we can use selective dropping 
> of packets at source, 
> > 25% (this is an arbitrary number, I have no idea whether 
> it's reasonable) 
> 
> Once again, see my obsolete draft. For random dropping and 
> not compensation,
> For SAToP, or nonvoice applications, it would seem that even 
> a few percent
> it is really bad.  So let's ask the fairness question at that point.
> 
> 
> Y(J)S
> 
>