Re: [RPRWG] MAC Question
Mike and Ray,
As Mike is saying no one has been proposing a token
scheme to avoid the traditional "collision" problem.
The buffer insertion scheme solves this and is not
round-trip-time sensitive.
There are however "token like" schemes proposed
for the fairness protocol. The fairness scheme
require nodes to interact by messages and they
may implicitly/explicitly include rights to
transmit packets, this is somewhat similar to
tokens.
Regarding the cut-through vers store-and-forward
the issue is if we should enforce store-and-forward
in all nodes. If the protocol supports cut-through
it is still ok to implement it as a store-and-forward
node and it is going to interoperate quite well if the
transit buffers are large versus MTU.
The benefits of cut-through are mainly two things. First,
the insertion (transit) buffer in a node can be smaller
than the MTU size on the ring. With a cut-through friendly
implementation a node can rely on a transit buffer
size proportional to its own tx MTU size instead of the
MTU on the ring. In such a system two nodes on the ring
may agree to use a 64kB MTU size and the other nodes
will not need to drop the jumbo packets. Second, latency
and jitter can be smaller.
From a practical perspective cut-through might result
in a tight (not good...) coupling between input and output
link rates. To aviod this, a minmal buffering corresponding
to max clock differences between incoming and outgoing link
are commonly used.
The cut-through discussion is also coming up during
discussions about supporting real-time traffic at
low link capacity. Again this is an old rat hole and
the conclusions are:
- If you use large packets, many nodes and/or links
with low capacity cut-through will win.
- If you use large capacity links, cut-through and
store-and-forward will give similar results.
During the last 802.17 meeting capacties between 10Mbps
and several 100's Gbps where mentioned.
My opinion is that we should target RPR as a cut-through
friendly mac to address the widest possible market for
the technology.
--Lars
Mike Takefman wrote:
> Ray,
>
> hopefully I will not step on anyone's toes in giving this
> answer.
>
> there are multiple approaches to this issue and there are
> trade-offs with each. However, everyone agrees on destination
> stripping of uni-cast packets and the need to allow multiple
> nodes on the ring to transmit simultaneously. Also,
> no one is (yet) proposing a token mechanism similar to
> .5.
>
> some people support a store and forward paradign on the ring
> where all packets are completely buffered on the transit
> path.
>
> there are at least 2 camps using the term cut-through to mean
> somewhat different things. they do agree on begining to
> transmit a transit packet as soon as possible. The difference
> is in the definition of as soon as possible and the size
> requirement on the transit buffer.
>
> cheers,
>
> mike