[e2e] on local ethernet throughput?

[Cannara]

Wenyu,

You are right that swicthed/bridged segments are more efficient than lumping
all the nodes onto one shared segment, whether Enet or any other shared
medium.  That, in fact, is why bridging was invented -- to split loads among
different node domains.  So, it's not surprising that a fast file xfer using
anything, will slow down other traffic on the same segment -- conservation of
capacity, regardless of collisions.  As we teach new LAN students, bridging is
a first-level opportunity to architect your network, by assigning nodes to
segments intelligently, thus dividing traffic patterns and gaining far more
overall throughput than one segment could achieve for the same nodes.

Alex


Wenyu Jiang wrote:
> 
> Hello,
>   Sorry about diverging the topic of this discussion.  I want to talk a
> bit about fairness between TCP and UDP on the ethernet.
> 
>   I am not an ethernet expert, but I have done a few experiments when a
> bulk TCP transfer and UDP multimedia stream occur simultaneously on a
> hub-switch hybrid setting.
> 
>         A -----hub-------------------switch------C
>            B----|                       |----D
> 
>   If there is a bulk TCP transfer in C->A direction, and B<->D is a duplex
> UDP connection (e.g., VoIP).  Then D->B has only a slightly higher delay,
> but B->D may experience severely high delay (e.g., > 200ms) (not
> continuously) for an extended period of time (lasting from about 100ms up
> to 800ms in my experiments).
>   TCP throughput of C->A is almost *not* affected by the UDP stream and
> the collisions.  However, it is evident that TCP in this case is not
> friendly at all to the UDP flows.
>   I used either ftp or ttcp for TCP bulk transfer.
> 
>   The delays are not always the same.  It may vary quite a lot depending
> on the switch/hub equipment, NIC, etc.  But it is at least possible for
> high delays to happen.
> 
>   My guess is that the vendors eventually decided not to bother with worst
> or average case analysis of collisions/delays, and use switching to avoid
> the problem altogether.  It may not be elegant, but at least works better
> than a hub architecture.  Certainly a VoIP user doesn't want to be
> disturbed by voice drop-outs whenever someones ftps, prints, downloads a
> large file.
>   Although 802.1p is designed to give media packets higher priority, it
> becomes useless in the face of heavy collisions with bulk TCP in a hub or
> hub/switch hybrid environment.  To avoid this, we can only resort to using
> a switch in place of a hub.  But then, having 802.1p probably doesn't
> matter as much because delays in switching is very low compared to
> that caused by collisions.  It seems like a dilemma.
>   So the use of switches has its advantage for lower delays in addition to
> more throughput.
>   Your comments are always welcome. Thanks.
> 
> Wenyu
> 
> On Sun, 21 Oct 2001, Cannara wrote:
> 
> > What Vernon says is quite right and I'll only add that Collision sensing and
> > recovery happens in times on the order of 200 uS to a few mS, on even
> > extremely highly contended Ethernet segments (many stations ready with pkts to
> > send all the time).  This is far faster than Token passing (many mS), in any
> > of its forms, as a very pertinent graph from the original IEEE 802
> > standarization simulations shows (it can be faxed to anyone who wishes a
> > copy).  This graph is particularly telling in that CSMA/CD become better in
> > relation to Token as the number of contending nodes increases -- yes, better.
> >
> > One reason for trying to rid the world of 'collision' myths is that they serve
> > as an alarm for how easily misinformation can arise and how hard it is to
> > gather peoples' intellects together to stamp the myths out.  Confining
> > ourselves to networking, we must be aware that this applies in the TCP/IP
> > realm as well.  Back to the LAN realm, which the original IP world had no
> > cognizance of, the collision myth, that started as an IBM marketing weapon,
> > matured into a switch vendors' scare tactic to sell at first cut-through (a
> > bad idea now in disrepute) and later "a segment for every node", so that
> > "collisions would no longer occur" -- just pushing the problem into
> > provisioning of the switch fabric.  "Caveat emptor" is as necessary today as
> > it has ever been.
> >
> > Alex