🚀 go-pugleaf

In article <4a7p2p$da3@access4.digex.net>,
zbang@access4.digex.net (Carl Zwanzig) wrote:

  > In fact, it's not Digex's problem. Not at all. What a 28.8 modem is
  > doing is almost like trying to drive your car (6'wide) through a
  > 6'-1" concrete tunnel. It can be done, but don't let the mirors stick
  > out too far, and make sure that the tunnel is REALLY 6'-1".
  > 
  > ...
  > 
  > Give credit where credit is due, if Digex connects 28.8 modems to the 
  > lines, but the lines refuse to carry the data, go after the carrier, 
  > not the provider.

This isn't quite right, either.  The original complaint dealt with...

>As background, traffic from the Baltimore area to the Beltsville
>site is routed down high capacity circuits known as the SLC 96 or 
>"slicks".  These trunks handle traffic in the 200 Hz to 3300 Hz
>range.  Modems operate at the high end of  this range, and 28.8 Kbps
>modems negotiate at a frequency of 3750 Hz.  The "slicks," in  
>other words, cannot support a 28.8 Kbps connection over the phone
>network.  Therefore, DIGEX cannot guarantee 28.8 Kbps access to its 
>customers at this time.  The "slicks" are guaranteed by the 
>manufacturer to support 19.2 Kbps connects, but they are only part of the 
>total connection from the customer site to DIGEX.  

So, what I gather Digex is doing is (to use the old terminology I'm
comfortable with) acquiring calls at local numbers remote from their site,
and using BA-provided equipment to multiplex or otherwise channel those
calls to their central location.

If the problem /is/ occurring before the call reaches the Digex number at
the remote location, then of course Digex isn't responsible for the
handshake only taking place at lower speeds.  However, if the user's modem
can connect with the Digex modem at (say) 28.8, but equipment which Digex
contracted for to take that data to another location is throttling the
speed down significantly, then it /is/ Digex's fault.  More expensive lines
can be acquired (or higher-speed lines multiplexed), and it is /not/ the
user's or the universe's fault that Digex elected a transmission path that
couldn't handle the load -- it's Digex's fault.  (And as others have made
clear, it's not TPC's fault, either -- they're providing what they were
paid to provide.)