Re: [RPRWG] temporal ordering requirement
Mike;
I was suggesting we amend our objective (or at least I think we had an
objective) at the March Plenary, that said we would maintain temporal
ordering on the ring on a QoS basis. This allows for per QoS queuing at
each node, and allows for low latency traffic to enter the ring ahead of
best effort traffic already on the ring. I thought it would be a good
idea to expand that to a per conversation basis which would allow per
flow queue implementations (personally I think this is excessive but why
limit ourselves). Link aggregation 802.3ad had to define a temporal
ordering requirement, so I thought it would be a good idea to simply use
theirs.
You bring up another point (which I have been wondering about as well)
which is link aggregation with RPR rings. We should think about this an
objective as well.
Dave Brown
tak@xxxxxxxxx wrote:
>
> Dave,
>
> (with my cisco hat on)
>
> 1998 802.1D shows that data frames from the same src/dst pair
> and with the same priority should not be mis-ordered, but data
> frames of different priorities or data frames from
> different src/dst pairs can be re-ordered.
>
> I believe the advantages of allowing higher priority traffic
> to get ahead of lower priority traffic is desirable to
> keep latency and jitter low.
>
> The issue of link aggregation or its equivalent in an RPR setting
> is a different issue and one worth discussion at some point
> in the future.
>
> mike
>
> Dave Brown wrote:
> >
> > I suggest we use the same temporal ordering requirement, that link
> > aggregation uses, for frames on an RPR ring.
> >
> > from 2000 802.3
> >
> > 1.4.94 Conversation: A set of MAC frames transmitted from one end
> > station to another, where all of the
> > MAC frames form an ordered sequence, and where the communicating end
> > stations require the ordering to
> > be maintained among the set of MAC frames exchanged. (See IEEE 802.3
> > Clause 43.)
> >
> > Dave.