Alternatives to Comcast

[Dave Johnson]

Ben Scott writes:
>   If what you see from your "modem" is PPPoE, then what happens is:
> Your PC builds an IP connection over PPP.  It puts the PPP frames into
> Ethernet frames and sends them to the modem.  The modem takes the PPP
> frames off Ethernet and puts them in ATM frames and beams them over
> the wire.  At the DSLAM, the ATM frames go into whatever equipment
> Verizon has until they get to the IP provider.  The IP provider takes
> the PPP frames out of the ATM frames and does IP routing with them.
> 
>   If what you see from your "modem" is IP-over-Ethernet (RFC-894),
> then the "modem" is either doing PPP termination locally and acting as
> a router, or it's encapsulating IP datagrams in ATM frames.  (Some
> implementations are worse, and encapsulate the entire Ethernet frame
> in the ATM frames.)  If the former, from the modem onward it's the
> same as for the PPPoE drill above.  For the later, the encapsulated
> frames get to the IP provider, are dencapsulated, and then handled
> appropriately.
> 
>   Vitts Networks was one of the providers doing the "worse"
> Ethernet-over-ATM scenario I describe.  Their DSL "modem" was
> basically just an Ethernet bridge.  In the CO, they had boxes which
> basically took DSL on one side and spit Ethernet out the other.  Then
> they'd patch each Ethernet port into a managed switch.  So now instead
> of running PPP over the serial DSL, you're running an emulation of
> broadcast-based Ethernet, which actually had *higher* overhead than
> PPP would have.

that sounds bad...

For both VZ's PPPoE direct customers and those customers that
have a different ISP, the dsl modem puts your packets directy into
AAL5 ATM and send them over a VC to the CO (VPI/VCI 0/32 if I
recall).

for Bridged IPoE, that's IP over ETH over LLC/SNAP over AAL5 over ATM


For anyone with a westell brand dsl modem on VZ you may be interested
in a program I wrote to gather data from the modem.

It sends the modem magic packets that cause it to send statistics data
periodically to the LAN.  The modem uses a multicast group to send
these, I gather that it uses multicast packets because in a bridged
configuration the device doesnt' have an IP address (at least not one
that you are supposed to see from your LAN).

http://davej.org/programs/westell.tgz

The program can generate human or machine readable output peridically
such as:

> $ westell --monitor --rate 10
> Waiting for Packet
> Got packet on 2008-05-22-09:20:34:
>   Status                 : online
>   Uptime                 : 214D 20H 44M (since 2007-10-20-12:35:40)
>   Upstream
>     Signal/Noise Ratio   : 12.0 db 
>     Power                : 12.0 dbm
>     Attenuation          : 27.0 db 
>     Data Rate (kbps)     : 864 atm, 782 aal5, 764 1500byte, 522 64byte
>   Downstream
>     Signal/Noise Ratio   :  5.5 db           [ -0.5 db ]
>     Power                : 16.5 dbm
>     Attenuation          : 47.0 db 
>     Data Rate (kbps)     : 3360 atm, 3043 aal5, 2972 1500byte, 2029 64byte
>   ATM
>     Signal Lost          :          0
>     Frame Lost           :          0
>     FEC Errors           :          0
>     CRC Errors           :       5655
>     HEC Errors           :       3068
>     OAM Cells            :        527
>     Loopback Cells       :          0
>     TX Cells             :   13172471        [ 16616 cells,  705 kbps ]
>     RX Cells             :   14095746        [   543 cells,   23 kbps ]
>   ETH
>     Dropped Packets      :        150
>     TX Packets           :  229991791        [     264 ]
>     RX Packets           :  249194133        [     524 ]

I've tested the program on both my Bridged non-VZ-ISP connection and a
PPPoE VZ-ISP connection of a friend. It seems to work on PPPoE however
the data rate calculations for may be off due to the different
encapsulation..

It's good to note VZ provisions the raw data rate higher than
advertised so that once the LLC/SNAP header, AAL5 trailer and ATM cell
header is removed, a 1500 byte IP packet can run at the advertised
bandwidth. Unfortunately smaller packets suffer due to the 32 bytes of
overhead plus sawtooth effect of ATM SARing.  My 3mb downstream rate
is only 2mb with 64 byte IP packets.

-- 
Dave