| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Wolfram,
I do agree with your analysis, and
like to amplify
two points you made (and you may or may not agree
that
these two are as important as I make it to
be).
1. We are not standardizing overall QoS
architecture. What
we are building is fair-access method of
the shared medium
ring MAC that is CoS-aware. All discussions of
DiffServ/802.1P
class definition is applicable to queue on
the buffer-insertion
path, not to the fair-access aspect of the
shared ring access.
My observation is that the vocal part of
this reflector is
converging to 3 CoS awareness, with very
specific behavior of
each. If enough discussion has
occurred on this matter, we
should be able to vote on this on our next
meeting. If you
feel otherwise, speak up (or speak up
further).
2. Store-and-Forward, versus Cut-Through, may be a
non-issue for
high-speed (e.g. >=2.5G) network to
meet jitter/delay, etc.
requirements for
non-data (e.g. TDM, VoIP) payload.
My preference on this matter is to
allow for both, so long as
interoperability is not compromised for
MACs >=1G. We do this
by specifying max. latency specification
for a transit frame
when ring input had been in idle. So
it is tied to the objectives
of specifying Ring MAC >=1G.
15xx byte Store-and-Forward
provides 3.1 mS latency for 256 node
ring at 1G w/o fiber link length
delay. 256 node, with 40 Km
between any two adjacent nodes provide
latency of
(40 Km/link
/ (250 m/uSec))*256 links = 41
mS.
So from latency point of view, unless
the network is provisioned,
it would not meet latency of <= 10 mS
for voice type of payload.
Jitter performance will be different
between the two. But since
any assumption I make in this area is
expected to be controversial,
I'll leave it up to the advocates of each
camp. But I would still
like to pursue max. jitter specification
within the context of the
fair access mechanism discussed in
#1. The jitter performance is
a gross function of the two, fair-access
MAC behavior and transit
buffer behavior.
regards,
Yong.
============================================
Yongbum "Yong" Kim Direct (408)922-7502 Technical Director Mobile (408)887-1058 3151 Zanker Road Fax (408)922-7530 San Jose, CA 95134 Main (408)501-7800 ybkim@xxxxxxxxxxxx www.broadcom.com ============================================ -----Original Message-----
From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On Behalf Of Harmen van As Sent: Thursday, April 05, 2001 6:05 AM To: stds-802-17@xxxxxxxx Cc: Wolfram Lemppenau Subject: RE: [RPRWG] Scheduling Based on the recent email discussion on
scheduling, my following comments.
First, MAC-protocols on rings are required to
coordinate access to the shared medium in a fair manner. If one omits
this protocol, one easily can construct cases where some of the nodes
are unable to transmit. Thus, the MAC will be a crucial part of the
standard.
For ring-speeds of 1 Gbit/s and above, the shared
media can only exploited by simultaneaous access to the medium by many nodes and
by destination removal).
Here, there are only two mechanisms, either a
slotted transmission structure (ATM) or buffer insertion to cope with variable
packet lengths (IP). In case of a slotted structure, packets have to be
segmented at the transmit nodes and reassembled at the receiver nodes. In a ring
with n nodes, each receiver node should have n reassembly machines. With
insertion buffers (transit buffers) complete IP packet can be handled, and this
is today the preferred way. Any thoughts in direction of 802.5 and FDDI
for medium access make no sense.
The insertion buffers are in the transmission path
and therefore all decisions have to operate at full link speeds. Buffers and
complicated scheduling as in Diffserv at 10 Gbit/s, or in future even above that
bit rate, are doable but require a lot of silicon space. Thus, are costly. It
should be the goal to create a standard that allows a small insertion buffer
size and rather simple scheduling. Three classes of traffic on the ring, as
already discussed in emails, would fit completely. This already means that three
parallel insertion buffers must be handled at link speed. This parallel
structure is required to allow for overtaking of packets between the three
priority classes. The jitter of the lowest class becomes of course larger,
but the delay bounds of the higher class traffics can be guaranteed, which is
the most crucial factor in IP-telephony and IP-multimedia. Other QoS policies
should be done above the MAC. Ring nodes should be considered as nodes that have
shared transmission links to all other nodes. Once the packet is given to
the MAC or clocked onto the transmission medium, there is no need for level-3,
etc switching control.
Having a long history in the design and
implementaion of multi-Gbit/s shared-medium rings, the buffers in the
transit path operate for me, without any discussion, always in
cut-through mode. Once on the medium, the packet should be delivered to the
destination with minimal interference by the access traffic of the same
class. I recently learned however that in contrast to my assumption, the
Cisco SRP operates their transit buffers as store-and-foreward. Each
packet is completely received in the transit buffer before forwarding.
Performance will show the difference in end-to-end delay. I like to point out that end-to-end delay will become the most
dominant performance measure in the very near future.The requirements of the
carriers will change when IP-telephony and IP-MM becomes a commodity and
carrier-grade service have to be guaranteed in a simular fashion as in
circuit-switching. When considering only 2.5 Gbit/s and 10 Gbit/s SONET/SDH or
10 GbE the difference will not be very crucial. However, for rings in the lower
bit-rate region in public access, campus, or in-building areas,
providing a huge market, the difference might have an impact on a
broad success of the standard. Scheduling between the insertion
buffers and the transmit buffers can in the same way be done both in
cut-through and store-and-foreward mode. In principle, rings with cut-through
and store-and-forward nodes having the same buffer structure would work
together. Even scheduling between buffers could be different. What has to
be the same is the MAC fairness mechanism.
Best regards
Harmen R. van As
------------------------------------------------------------------
Prof.Dr. Harmen R. van As Institute of Communication Networks Head of Institute Vienna University of Technology Tel +43-1-58801-38800 Favoritenstrasse 9/388 Fax +43-1-58801-38898 A-1040 Vienna, Austria http://www.ikn.tuwien.ac.at email: Harmen.R.van-As@xxxxxxxxxxxx ------------------------------------------------------------------ |