Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[RPRWG] perf: Store and Forward (again)




Hi all,

Despite the fact that IMHO the st&F vs cut through 
should be implementation and not standard, here is
an issue I'd like to raise: 

Consider a chain of RPR macs (say part of a ring):
MAC1-->MAC2-->/.../MACN
suppose that a traffic pattern enters MAC1 and exits
MACN without any drop (N hops). Suppose that they
are all st&f. What will happen is that long packets will
be delayed longer than short packets in the st&f buffers.
Thus large packets see that shorter packets start creeping
up on them from behind, until they bump into each other
and clump. Thus, traffic patterns entering such a "passive" chain
of MAC's will undergo some kind of statistics change in favor of 
longer bursts of packet trains (I forget the exact term used in the terms
and defs, sorry).

This is bound to have adverse effects on the delays packets suffer while
entering the ring (which may be solved by increasing the transit buffer
size).
 How adverse? At the moment we (=NN)have only indirect evidence
for this happening at all, but for 90% utilization and several 10's of
MAC's, we can expect
that all the largest packets (say 1500 for ethernet) are always followed by
an entourage of shorter
packets. If one assumes that long packets are about 10% of the total
bandwidth, I guess
that a "typical" entourage is about 10 large packets long. Much longer
bursts are also possible.

Another effect this may have is if the MAC is connected to the egress
through several "thin" ports.
In this case, a single thin port may be bombarded at the full ring rate for
a period that is much longer
than what cut through needs. This has implications on buffer sizes as well.

Question to the group: Have people who studied ST&F vs cut through taken
this into consideration?
Is it really as bad as the back on an envelope gives?

reuven

--------------------------------------------------------------------
Reuven Zeitak PhD

Modeling And Algorithms 
Native Networks
2 Granit St., P.O.Box 7165 
Petah Tikva, Israel
Tel: +972-3-920-2800 x 875
Fax: +972-3-9210080
reuven.zeitak@xxxxxxxxxxxxxxxxxx
www.nativenetworks.com
 
The Native Way = Ethernet Simplicity + SONET Reliability