Test

=

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
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3