RE: [RPRWG] temporal ordering requirement
It may be worth pointing out here that 802.3ad (link aggregation) talks
about
minimzation of out of ordering when a link assignment changes. I guess we
will have
to do the same thing here or put some number on how much out of ordering is
acceptable.
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct: (408)363-2375
Fax: (408)226-6862
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
> Behalf Of Necdet Uzun
> Sent: Friday, March 23, 2001 4:25 PM
> To: Yongbum Kim
> Cc: Dave Brown; tak@xxxxxxxxx; Brown_Dave/SEMI@xxxxxxxxxx;
> stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] temporal ordering requirement
>
>
> Yongkim,
>
> Just to clarify your last point, i.e., out of ordering during protection
> event,
> neither steering nor wrapping can totally eliminate out of ordering of
> packets.
> Steering can out of order packets right after protection event as well as
> right after
> restoration. However, wrapping without steering ensures order of packets
> right after
> going into wrap, though coming back from wrap may cause out of ordering.
> Wrapping then steering can out of order packets in both scenarios.
>
> The issue is not just how bad is the out of ordering of packets
> but also how
> fast you can go into
> protection mode, and how scalable the protection scheme is.
>
> Thanks.
>
> Necdet
>
> Yongbum Kim wrote:
>
> > Dear Dave,
> >
> > The group is in process of voting on objectives
> > list @ last and next meeting -- I am hopeful that we separate
> > contentious issues from agreeable ones. This issue WILL be
> > discussed.
> >
> > That said, the issue Mike talked about, SRC-DEST must be
> > delivered in order, is 802.1 requirement, which also is 802
> > architecture requirement. I do not believe this is up for discussion
> > (unless the group feels strongly enough to change 802 architecture).
> > 802.1D Bridges, most implementations meet this requirement by not
> > allowing ANY mis-ordering. 802.1Q bridges do the same within same CoS.
> >
> > As for mis-ordering during protection event, I look forward to
> > further presentation on this matter, addressing fastest protection
> > versus allowing mis-ordering, and how one is a more evil than the other.
> >
> > 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 Dave Brown
> > Sent: Friday, March 23, 2001 10:08 AM
> > To: tak@xxxxxxxxx
> > Cc: Brown_Dave/SEMI@xxxxxxxxxx; stds-802-17@xxxxxxxx
> > Subject: 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.
>