Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe
From: kwe@bu-it.bu.edu (Kent England)
Newsgroups: comp.dcom.lans
Subject: Re: Do multiport repeaters buffer packets?
Message-ID: <63258@bu.edu.bu.edu>
Date: 27 Aug 90 16:51:44 GMT
References: <65056@yarra.oz.au>
Sender: news@bu.edu.bu.edu
Reply-To: kwe@bu-it.bu.edu (Kent England)
Organization: Boston University
Lines: 46

In article <65056@yarra.oz.au>, chris@yarra.oz.au (Chris Jankowski) writes:
> 
> Most Ethernet and IEEE.802.3 LANs design guidelines recommend use
> of multiport repeaters ...
> Just consider the following example:
> Assume that N-1 PCs each on different Ethernet segment generates a packet
> directed to the server at the same time. Even if the server's Ethernet
> segment is quiet only one of those packets can be delivered at a time.
> What happens with the others? 
> Does the N port repeater buffer the remaining frames?
> If not (and I believe that store and forward is a function of a bridge)
> what other strategy can a multiport repeater use?
> Or am I missing something important altogether?
> 
	There have been several messages lately about multiport bridges
(a new market niche) and what with 10BaseT multi-ports et al, perhaps it
is time
to re-cover some fundamentals:

	"Repeaters" are bit level devices.  That means that all they
do is receive digital signals (pulses), regenerate them, and pass them
on to all other ports.  They add a little delay into the picture, but
presumably less than a bit time (negligible).  	Repeaters propagate collisions.

	A "bridge" is a frame-level device.  It can read Ethernet addresses,
can mate Ethernet to other media (like broadband or TR), and can filter
frames for reducing traffic loading.

	Until the advent of some of the new multiport bridges, all
bridges would swallow a frame from one port before scanning it and
either forwarding the frame or dropping it.  This allowed for the
decoupling of the collision process between the two bridged segments.

	At least one multi-port bridge maker (Kalpana) claims to forward
frames as soon as the dest-addr can be parsed and compared to the table.
This begs the question (first heard from Walt Haas in Utah) about what
that does to the collision process.  I believe that Walt is asking Kalpana
what they do about that.  Kalpana wants to minimize latency as an aid
to improving performance for simple LAN protocols on Ethernet.

	As chips that do bridging become cheaper, we are bound to see
some multi-port repeater makers come out with multi-port bridged
concentrators, as well as more players in the high-performance multi-
port bridge game.

	--Kent