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

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

Xref: sparky comp.protocols.nfs:3193 comp.dcom.isdn:1203
Path: sparky!uunet!olivea!gossip.pyramid.com!pyramid!infmx!johng
From: [e-mail] (John Galloway)
Newsgroups: comp.protocols.nfs,comp.dcom.isdn
Subject: Re: Low cost ether/isdn brouters (was PC-NFS PPP Serial/ISDN driver wanted)
Message-ID: <[e-mail]>
Date: 22 Jan 93 00:20:29 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Usenet News)
Organization: Informix Software, Inc.
Lines: 89

In article <[e-mail]> [e-mail] (Dave Carr) writes:
>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.

Educate me if you would, on just what is the difference (in function and use)
of a TA Vs. an NT1.
>
>>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?
A bridge (in my understanding) just exchanges ethernet packets between
to nets, perhaps with filtering.  Nodes on the same ethernet must be
in the same IP network.  All this is fine if using a bridge to really
bridge to nets.  However suppose you are using ISDN to access the global
Internet, i.e. this is your feed from a network provider.  In this case
it would be a pain to have to group people into Class C sized nets, and
put there host end of the isdn connection on a seperate ether etc.  Using
full router functionality in the ether/isdn <-> isdn/ether setup allows
more flexibility.  Or so it seems.
>
>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.
>
I wasn't being really specific on RIP etc.  basically I just want a box
that sits on my ethernet, and talks to my host(s) to get net info, configures
itself and works.  I supply my IP addr, and a phone number and thats it.

>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.
>
> [error processing thoughts deleted]
>
>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.
Seems like a good point, the faster you can detect an error and retransmit
the better, as longs as its cheap in terms of overhead on good packets and
hw costs.
>
>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).
This is an area I am not clear on (in fact the biggest problem in
interoperability between isdn vendors seems to be how they implemnt the
2 B channels).  I assume "bonding" is some sort of synchronized action
between the channels?  It seems like running them seperatly would be
a good idea, excpet for the degenerate case of some app wanting an
ack after each packet and thus not being able to make use of the
higher performnce (since a single tcp/ip -> ethernet packet would go
entirely onto one channel), but that a stupid app.
    -jrg


--
internet    [e-mail]  John R. Galloway, Jr  795 Beaver Creek Way
internet    [e-mail]     CEO...receptionist    San Jose, CA   95133
applelink   D3413                  Galloway Research     [phone]