Re: [RPRWG] Why are current RPR proposals too complicated to be deplyed and maintained by service providers????
Robert:
Thanks for the explanations. I'd like to put in a point about standardization of
internal elements.
Robert Castellano wrote:
> We also don't need to standardize the sophisticated access control methods
> which are being proposed or solve any head-line blocking problems.
I fully agree with you; we shouldn't standardize sophisticated access control
methods that solve head-of-line (HOL) blocking problems. In fact, the RPR MAC
shouldn't standardize internal queuing and buffering structures. These are
internal device implementation details, and these should be left to device
designers
HOL is an issue that came out of discussions during RPR WG meetings. Some
proposals that resulted from earlier implementations have major problems with
HOL and they simply don't support it. This happened because apparently the
designers of those protocols weren't aware of it at the time.
When a node sends a congestion message upstream, the upstream nodes should be
able to block traffic to that node without blocking traffic to other nodes. The
RPR MAC should simply specify that a MAC device SHALL NOT block packets to
non-congested nodes. Precisely _how_ a MAC device achieves this should be left
to the MAC device developer. If some MAC implementations cannot support it, that
that implementation would be non-compliant. It should be that simple.
It is good you brought this point, because I see too many people are hung up on
how many buffers/queues are present inside an RPR MAC. The RPR MAC standard
should simply specify that it supports (or doesn't inhibit support of )
diff-serv (if it inhibits support for L3-level assignment of diff-serv there
could be problem), with a definition of tolerance limits for different types of
services. Now, how how a particular implementation internally supports it
shouldn't be part of the RPR MAC standard. A lot of people are busy describing
internal block diagram of a MAC device. In fact, they are trying to shove their
internal implementations (some of them quite old) into RPR MAC standard draft.
This is not innovation, and this shouldn't be part of MAC standard
specification.
If internal buffer implementations would become part of standard, how would a
customer choose a MAC device? Would he ask for internal design details of the
chip? Would he demand Verilog/VHDL models? At a later stage, if someone comes
up with a better queuing scheme, would the vendor be in violation for not
conforming to an obsolete queuing scheme? For IEEE 802.3, you can buy MAC
devices from a number of vendors without ever have to look inside the MAC chip.
The same should be true for RPR MAC standard.
Limitations of a certain MAC implementation should stay as limitations of that
particular MAC implementation - not slide their way into becoming a standard for
the industry to follow for years to come. For instance, let us consider a the
least performance case that suffers from HOL and other problems - if a certain
implementation has only two (or three) buffers, and it shoves all except the
highest priority packets into its low-priority, best-effort queue it cannot
really claim a diff-serv support. RPR MAC standard should specify support for
diff-serv, with MUST for some levels, and SHOULD for other levels so that
limited implementations would also be able to work with RPR.
With time, MAC implementations would get more sophisticated and other MAC
implementations may provide per-class queuing support, some may also have
per-class and per-node queuing support as technology evolves. The standard
should specify MUST, SHOULD HAVE, MAY HAVE, etc. and not get focused on
implementation details.
It is unfortunate that vendors are bringing their age-old implementations and
trying to shove it down RPR WG to standardize their particular implementation.
It also brings forth their assertion that all of the RPR issues that RPR WG has
been discussing (vendor presentations, carriers and other providers' viewpoints
and issues, etc.) in all these meetings were already figured out by them years
ago, and no further research needs to be carried out. Instead of spending time
drumming up support from other individuals to vote for their limited
implementations, it would be better if people spend their time in improving the
standards specification so RPR MAC standard can be successful in the
marketplace.
Regards,
Pankaj