Subject: RE: [PWE3] [Fwd: Proposed text for SAToP congestion section]

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 29 Dec 2005 15:37:04 +0200

> 8.  Congestion Control
>
> As explained in [PWE3-ARCH], the PSN carrying the PW may be subject to

> congestion, with congestion characteristics depending on PSN type, 
> network architecture, configuration, and loading. During congestion 
> the PSN may exhibit packet loss and PDV that will impact

s/will/might/ ... since it is the goal that it *not* impact the PW.

[YJS] OK - reasonable

> the timing and data integrity of the SAToP PW.  During intervals of 
> accute congestion SAToP will not be able to maintain service.

If the PW is engineered with sufficient resources, then congestion alone
will not be a problem, since other traffic could be dropped as needed.
Failures might be a problem but not congestion itself.
Perhaps you could say "during intervals of acute resource shortage".

[YJS] I don't see the major difference between congestion and "acute
resource shortage".
In any case, the title of the section is "congestion control",
and we were specifically asked to provide a solution for what
SAToP does under "congestion".

> In
> addition, since SAToP PWs carry constant bit rate (CBR) services 
> across the PSN, they cannot behave in a TCP-friendly manner prescribed

> by [RFC2914].  In the presence of services that reduce transmission 
> rate, SAToP PWs will thus consume more than their fair share (although

> being CBR, the percentage of total bandwidth they consume remains 
> constant)

I don't understand combining "fair share" and CBR.  When you engineer a
PW for CBR, it removes it from consideration of "fairness" of
distribution of resources.  I would delete this paragraph ...

[YJS] Unfortunately, this is precisely the paragraph we were asked
to write in Allison's DISCUSS.

> and SHOULD be halted.

... except for this.  During intervals of acute resource shortage, when
the PW service requirements cannot be met, the service should be halted.

[YJS] you mean SHOULD :)

> Whenever possible, SAToP PWs should be run over traffic-engineered 
> PSNs providing bandwidth allocation and admission control mechanisms.

> IntServ-enabled domains providing the Guaranteed Service (GS) or 
> DiffServ-enabled domains using EF (expedited
> forwarding) are examples of traffic-engineered PSNs. Such PSNs will 
> minimize loss and delay while providing some degree of isolation of 
> the SAToP PW's effects from neighboring streams.

I would move this paragraph up to the top.  Considerations of all of the
other issues depend on this.

[YJS] Actually I tried this in one of the first attempts.
I believe that we should start with what the architecture draft
tells us, and then differentiate between the best effort
and the TE cases. Only then does it make sense to say
that TE SHOULD be used IF AVAILABLE.

> The PEs SHOULD monitor for congestion (by using explicit congestion 
> notification, VCCV, or by measuring packet loss) in order to ensure 
> that the SAToP service may be maintained. Note that SAToP packet loss 
> rate may always be measured unintrusively since the expected packet 
> arrival rate is known and fixed.  When significant congestion is 
> detected the SAToP service SHOULD be terminated.

Again, congestion itself is not the problem.  "Resource shortage" as a
general term?

[YJS] as above

The rest is okay.

[YJS]  :)

Thanks ... Scott

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

---

From: Eric W Gray <[email-masked]>
Date: Thu, 29 Dec 2005 13:44:15 -0500

Yaakov,

    Think of the difference between "congestion" and "acute resource 
shortage" in perhaps more familiar
terms of breathing difficulty.  Congestion is in fact a frequent, if not 
normal, condition.  Acute resource
shortage is pathological.

    We should not attempt to dictate how services are treated under what 
is likely to be a common  mode.

    As for discontinuing a CBR service because it is consuming more than 
a "fair share", perhaps you did
not understand the AD's comments, or perhaps those comments are wrong.  
It is not particulary meaningful
to define a CBR service if it does not continue to provide CBR delivery 
under conditions of competition for
(possibly scarce) resources.

--
Eric