Subject: [Tsvwg] Re: [PWE3] PWE3 congestion design team

From: Bob Briscoe <[email-masked]>
Date: Thu, 13 Jul 2006 13:00:45 +0100

Manu,

At 00:40 12/07/2006, [email-masked] wrote:
>May I kindly urge this WG not to go down this road ...:-(0

If by "this road" you mean generic edge-edge congestion control for PWEs, I 
agree it's a road we should not travel.

But we should travel the road of documenting why not.

And we should travel the road of considering whether certain types of PWE3 
might (or probably will) cause congestion problems and what to do about them.

For instance, for CBR-like PWEs (strictly those that have a high ratio of 
mean to peak rate), *admission control* based on edge-edge congestion 
measurements is feasible based on the PCN work progressing in the transport 
area:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#CL-deploy>, as long as 
the PWE bit rate is at least a couple of orders of magnitude less than the 
links it traverses.

On-off congestion control (ie admission control) isn't such a can of worms 
as TCP-like congestion control, and my gut feeling is that these sorts of 
PWEs are the real cause for concern because, when they are set up or torn 
down, large aggregates suddenly appear or disappear without caring about 
everyone else. Perhaps the PWE w-g should simply encourage this PCN 
approach for CBR-like PWEs? Perhaps we should present this work at the next 
PWE mtg to see if we have a meeting of minds?

If there's more variable traffic within a PWE, the endpoint transport 
layers beyond the ends of the PWE may be responding to congestion signals. 
But they may not. If not, it's not so different to the problem the general 
Internet has, with the increase in use of unresponsive apps (VoIP, video 
streaming).

The only difference is in the expectations that the term 'pseudo-wire' 
conjours in the minds of those that don't live and breath the Internet 
congestion control architecture. The constituency that is used to the 
transport being *below* the network layer end up using the Internet as if 
it was like this, but it isn't.

My last mail also pointed to architectural work that would allow the 
network to police/enforce congestion control, whether for PWEs or not.
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#retcp>
I don't believe the PWE w-g should have to solve that more general (and 
very hard) problem.

Cheers

Bob

>Anyone ever heard of the TM WG of the former ATM Forum and what actually
>got deployed ...:-(0
>
>Does Available Bit Rate ring a bell??
>
>@+ manu
>
>
>
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: "Kenney, John B." <[email-masked]>
Date: Tue, 18 Jul 2006 12:44:58 -0500

I agree with Bob that we should look into this and have something to
say, and that a PW-level feedback-based congestion control function is
probably not needed.  

Cheers,
John

-----Original Message-----
From: Bob Briscoe [mailto:[email-masked]] 
Sent: Thursday, July 13, 2006 8:01 AM
To: [email-masked]
Cc: [email-masked]; tsvwg
Subject: Re: [PWE3] PWE3 congestion design team

Manu,

>May I kindly urge this WG not to go down this road ...:-(0

If by "this road" you mean generic edge-edge congestion control for
PWEs, I 
agree it's a road we should not travel.

And we should travel the road of considering whether certain types of
PWE3 
might (or probably will) cause congestion problems and what to do about
them.

For instance, for CBR-like PWEs (strictly those that have a high ratio
of 
mean to peak rate), *admission control* based on edge-edge congestion 
measurements is feasible based on the PCN work progressing in the
transport 
area:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#CL-deploy>, as long
as 
the PWE bit rate is at least a couple of orders of magnitude less than
the 
links it traverses.

On-off congestion control (ie admission control) isn't such a can of
worms 
as TCP-like congestion control, and my gut feeling is that these sorts
of 
PWEs are the real cause for concern because, when they are set up or
torn 
down, large aggregates suddenly appear or disappear without caring about

everyone else. Perhaps the PWE w-g should simply encourage this PCN 
approach for CBR-like PWEs? Perhaps we should present this work at the
next 
PWE mtg to see if we have a meeting of minds?

If there's more variable traffic within a PWE, the endpoint transport 
layers beyond the ends of the PWE may be responding to congestion
signals. 
But they may not. If not, it's not so different to the problem the
general 
Internet has, with the increase in use of unresponsive apps (VoIP, video

streaming).

transport being *below* the network layer end up using the Internet as
if 

Cheers

Bob

>Does Available Bit Rate ring a bell??

________________________________________________________________________
____
Notice: This contribution is the personal view of the author and does
not 
necessarily reflect the technical nor commercial direction of BT plc.
________________________________________________________________________
____
Bob Briscoe,                           Networks Research Centre, BT
Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
645196 

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================