[e2e] on local ethernet throughput?

[Wenyu Jiang]

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
>