The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1997-May> msg00191



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

AW: Re: RBOCs Reaching Limits, DSLAM, xD

  • From: TG6124 <tg6124@topmail1.sbc.com>
  • Date: Thu, 22 May 1997 10:13:55 -0500
  • Cc: "'ion@nexen.com'" <ion@nexen.com>


-----Original Message-----
From:	Jon Crowcroft [SMTP:J.Crowcroft@cs.ucl.ac.uk]
Sent:	Thursday, May 22, 1997 8:20 AM
To:	TG6124
Cc:	'ion@nexen.com'; J.Crowcroft@cs.ucl.ac.uk
Subject:	Re: AW: Re: RBOCs Reaching Limits, DSLAM, xD


 >>You make the assertion that we need both types of paradigms but 
 >>do not discuss how they will be implemented. Same networks, 
 >>separate networks, costs, availability, customer impact, etc. A network
 >>can change from over-engineered to under-engineered in a matter of 
 >>days or even hours. How do you change the paradigm used on a 
 >>network in the same amount of time? It would seem to me that some
 >>strategic decisions need to be made early on in the process to handle
 >>such a situation. Much of the discussion has been at the strategic
 >>level. Can you advance the discussion?
 
>flow labelling....for example....with self tuning flow detection
>filters....

In other words, built in resource management routines. But note also 
that network users need to understand what is happening to their 
flows to make their own strategic and tactical decisions concerning
their data, which is what is being carried on the network. If because 
the network suddenly moves from over-engineered to under-
engineered you begin dropping some data from some flows or to 
blocking some flows how do you notify the customers?