|
Lu,
I'm
interested in solving applications similar to yours which demand very low delay,
jitter, and loss. I think some of our customers
can
provide the same service. Unfortunately, the ring is not the only medium, there
are many rings involved where jitter accumulation occurs.
Prof.
Huang had presented theoretical upper bound calculations for single
transit buffer design on one ring in a previous meeting.
As the
ad hoc group progresses, we should highlight the trade-off and respect others'
applications demanding different
behaviors. This is what makes RPR better than what's
out there today because it can adapt optimally to other
applications.
If you
can buy a box that is optimized for your application all the better to that box
vendor and your success.
At the
MAC level it will should interwork.
Regards,
Harry
p.s.
Can you remind me
as to who are the unbiased presenters you refer
to?
I
would like to elaborate on my concerns at the Reservation Ad Hoc
meeting.
As I
see it, the reserved, or non-reclaimable class of bandwidth was created
as a means of compromising between the two approaches of congestion avoidance
and congestion recovery. Though I applaud the compromise,
It has not been demonstrated that with a congestion recovery scheme
you can have a single transit buffer and yet guarantee bounded
jitter.
I
would like to believe Necdet in nu_reserved_01.ppt, but he only discusses a
steady-state, doesn't show details of transit buffers, and doesn't cover any
corner cases. My *normal* case is one that most of you might
consider a corner case (VOD over 80% of the bandwidth). In my May
'01 presentation I predicted a market for RPR in cable
television Video-On-Demand transport that is more than realizing my
expectations, but being serviced by wavelengths of Gigabit
Ethernet (see lr_evor_01.pdf from May '01 interim).
Last
week we heard respected and unbiased presenters raise some serious concerns
over our scheme. I am not a veteran of networking standards, but
surely we won't dismiss these and make decisions without some analytical proof
or thorough simulations that we can all agree on.
I am
encouraged that we are close to a standard here, but am asking for a
simple due-diligence on our part.
Lu
Rovira
The Rate Ad Hoc (hence known as RAH) met and agreed to
discuss concerns and then plan how to continue. The following people
expressed the following concerns.
Necdet Uzun: No packet loss on ring; not preclude STB;
not complicate MAC design; high priority should be shaped to CBR; jitter can
be worsened by control packets; ring not owned/operated by one entity, can
trust all MACs, but not all clients
John Lemon:
STB (or small second buffer of DTB) doesn't compromise DTB on same
ring, such as effecting jitter sensitive traffic; reservation per link,
different allowed; reserved traffic jitter bounded by N MTU; topology
negotiated secondary buffer size determining ramp up of low pri traffic;
loss < jitter < utilization; not constrained by 802 bridging, just
support superset of 802 bridging - dumb client sends all BE traffic
Harry Peng: STB design is not precluded; must interop,
but maybe at slightly reduced performance; separation of access jitter and
transit jitter; constrained by 802 bridging compliance, make sure we don't
break it
Luis Rovira: concerned about complexity; wants
simulation/calculation proof/certainty
Stein Gjessing: how do we specify what values are
advertised and how do we specify node's behavior to comply
Italo Busi: negotiate for priorities for loss, jitter,
utilization
Yiming Yao: allow customer to choose between loss,
jitter, and utilization
Anoop: should not preclude VDQ; should allow algorithm
other than ramp up/down
Other attendees: Tricia Hill, Vitorio
Mascolo, Yongdong Zhao, Rhett Brikovskis, Li Mo, Peter Jones.
Going forward:
- General interest
messages sent to reflector with titles starting with RAH
- Ad hoc bridge +
face to face (9:00 am PT, Tuesdays, starting 3/19), Necdet sets bridge
- Define priority,
reservation, reclamation, classes of service, etc and give usage
- Propose how to meet
all of above requirements
- Document
- Define scenarios to
evaluate against
- Simulate against
simulation reference model
-
- - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
This
e-mail and any attachments may contain information which is confidential,
proprietary, privileged or otherwise protected by law. The information is
solely intended for the named addressee (or a person responsible for
delivering it to the addressee). If you are not the intended recipient of this
message, you are not authorized to read, print, retain, copy or disseminate
this message or any part of it. If you have received this e-mail in error,
please notify the sender immediately by return e-mail and delete it from your
computer.
|