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

From: Stewart Bryant <[email-masked]>
Date: Tue, 03 Jan 2006 19:04:44 +0000

Eric W Gray wrote:

> 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.

Perhaps we should use the term severe congestion. No one is thinking
that we should shut down the TDM service because of a few dropped packets.

>
>     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.

Only up to a point. There will be some point at which CBR traffic load has
to be shed to allow higher priority TDM traffic to continue, or to allow 
the
network infrastruture itself to continue.

Perhaps the right analogy is with electricity supply. Cutting supply is 
very
serious and not done lightly, it is only done after more capacity has 
been added,
then the voltage has been reduced, and then even then the low priority 
users are
shut down first.

TDM shutdown should only be undertaken when it really is "the right
thing to do under the circumstances"

- Stewart

>
> --
> Eric
>
> Yaakov Stein wrote:
>
>> 
>>  
>>
>>>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
>>
>>
>>
>>  
>>
>------------------------------------------------------------------------
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>  
>

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

---

From: Scott W Brim <[email-masked]>
Date: Tue, 03 Jan 2006 14:36:02 -0500

On 01/03/2006 14:04 PM, Stewart Bryant allegedly wrote:
> There will be some point at which CBR traffic load has

For clarity, that's what should be said, rather than phrasing it in
terms of "fair share".