Subject: Re: PWE3 congestion

From: Philip Chimento <[email-masked]>
Date: Thu, 13 Feb 2003 14:16:29 -0500

Actually, I wasn't pointing out that these problems are non-trivial to 
say that they can't
be solved, just that they are hard, and that (I think) a different 
approach from that of
TCP needs to be considered. You can't make circuit emulation 
"TCP-friendly" because of the characteristics that they have due to the 
service they provide.

Neil's points about the management of different layers are well-taken, 
but rather different points.
I was just trying to start a discussion on the order of "what would a 
good solution look like?"

Regards, Phil Chimento

-- 
Phil Chimento             Ericsson IPI
Phone: 240-314-3597	  7301 Calhoun Place
[email-masked]   Rockville, Md. 20855
-----------------------------------------------------

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 13 Feb 2003 20:06:37 +0000

[email-masked] wrote:
> Stewart, please see below, regards, Neil
> 
> Stewart Bryant wrote 13 February 2003 16:50
> 
> <snip>
> 
>>What exactly do you mean by "managed properly"?
> 
> NH=> Simply this: If there is a client/server relationship between 2 layer
> network technologies  X/Y say, then its important that both X and Y can be
> operated/managed as layer networks in their own right.  So this embraces all
> the functional components one requires to do this, eg addressing, routing,
> signalling (not cnls obviously), fault-management, traffic management,
> performance management, etc.  In particular one should not be asking a given
> layer network (be it client or server to some other layer network) to proxy
> for functional deficiences in the other layer network....and in the specific
> case here there is an 'in-between' layer network that seems to be being
> created that looks like its taking on some of these proxying functions.
> 

...and I think that the architecture uses this functional partitioning
because the only sub-system that is allowed to modulate (by any method)
the payload flow is the NSP, which is part of what you call the client
network.

>>The requirement that MUST be addressed is to have a mechnanism that in
>>real time protects the network core from congestion collapse in a
>>fair way.
>>
>>In the case of non-TCP friendly traffic what is your 
>>technical proposal
>>for the design of an alternative congestion back-off mechnism?
> 
> NH=>The solution for protecting the network (get the source to slow down) is
> not trivial as Philip pointed out. How do you tell an ATM connection to slow
> down?  How do you tell a circuit emulation T1/E1 to slow down?
> 

You don't. You set a congestion threshold and if that threshold is
exceeded you tear down the PW.

> One way of addressing this is via signalling and CAC for known client
> demands on the server.....but of course it assumes these functions are
> available/specified in the server.....if they are not then perhaps one
> should not be doing this?

Remember the IESG is not going to approve PW unless there is a method
of protecting the Internet from congestion.

Stewart