NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/protocol/nfs/3173

Internet Message Format | 1993-01-21 | 4.1 KB

Xref: sparky comp.protocols.nfs:3173 comp.dcom.isdn:1190
Newsgroups: comp.protocols.nfs,comp.dcom.isdn
Path: sparky!uunet!cs.utexas.edu!torn!nott!hobbit.gandalf.ca!dcarr
From: [e-mail] (Dave Carr)
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Message-ID: <[e-mail]>
Organization: Gandalf Data Ltd.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Jan 1993 15:10:29 GMT
Lines: 67

In <[e-mail]> [e-mail] (John Galloway) writes:

>>At the other end of the scale, we do have a V.32 modem equivalent, the 5510
>>bridge.  It's lower cost (don't know price) and only handles a single

>   the 5510 retails for $1995 (at least from Advanced Internetowrk
>   Communications Inc., San Mateo)

I didn't realize that the price was so high.

>$625 would be great, but its likely only due to NOT operating in a monolopy
>that such a price will ever be seen.

What is more likely, as least from our perspective, is the cost of a TA will
fall to below that of the V.32 modems (once the volume get up).  Then, the
question is how cheaply can you add the ethernet port.

>Just 2x64k (uncompressed would be ok), with real router sw (SNMP, RIP, ARP,
>OSI?) rather than a filtering bridge is what I want. However it can be
>oriented to a very small net doing quite simple routing (i.e. its not due
>to a vast LAN at my house, but the fact that I, may, want a different network
>then the other end of the bridge, that makes me want a router rather than a
>bridge).

Interesting.  Could you tell me more.  With ISDN, we are basically talking
about a point-to-point link.  Our view is with the right software mods, you
can get the desired performance out of a bridge.  The trickiest part is the
handling of multicast and broadcast.  If we can eliminate these packets
without doing the entire routing function, do we have what you need?

SNMP management we have, ARP we will spoof, why RIP on point-to-point link,
and OSI that deserves its own sentence.  We now have OSI, but there is
little demand.

There isn't that much difference in performance between a bridge and a
router in terms of forwarding performance.  The big difference is the
100's of Kbytes of code to support the various stacks.

>  ALso I wonder if in a tcp/ip env V.42 type error control is
>even desireable.  i.e. it costs something and higher levels in the system
>(e.g. ftp) are doing their own error checking/retransmiting.  Right?

Compared to the overhead of any other link protocol, LAPB is cheap.  On
each packet, we add 3 bytes (modulo 128).  Actually, it's only a one byte
increase over just framing the data with flags, since we can use a 16 or
32 bit CRC on our frames.  Over digital links, do you need CRC32?  (We can
also pass the original CRC through if so configured).

Processing overhead is minimal in the case of a good packet.  Check and bump
the sequence number, pass up to the next layer.  When there is an error, it's
not that much code either.  If one uses selective reject, there is a definite
win.  The bridge can request the retransmission long before the hosts
recognize a frame is missing.  Even a router will not forward the packet
if the frame is corrupted over the WAN link, so the hosts will timeout.

BUT, there are 2 other benefits to running an error corrected link.  First,
multi-link, which means I can run 2 B-channels load balanced, without the
requirement for bonding.  The second is once I have error correction,
more powerful data compression algorithms can be used.  I'm not stuck with
VJ header stuff, but I can do it right, and to the data field on the
packet.  In terms of delay, the packet gets to the remote end sooner with
compression, even if retransmission is necessary (assuming >2:1).

Try running PC/TCP over a 64 Kbps link and you'll see what I mean.  The
PC/TCP timers are not dynamic, and timeouts will occur.  2B won't help.
You'll get about 8K bps out of your link.  But it runs just fine with
compression.