Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RPRWG] temporal ordering requirement




Pankaj, 

what I also failed to mention, is that I will try to use one of 
the floor microphones when wearing the hat to make it even 
more clear that I am speaking as an individual and not chair.

I appreciate all feedback that people have for me. I urge all 
members of the WG to contact me with any concerns they may have.

cheers, 

mike

Pankaj K Jha wrote:
> 
> I see your point. I wrote it because a good few people at the meeting thought
> the other way - that by putting Cisco hat you were (inadvertently) pushing
> Cisco viewpoints while the microphone was with you as a chair.
> 
> I think your concern makes perfect sense. Thanks a lot for the clarification.
> 
> -Pankaj
> 
> Mike Takefman wrote:
> 
> > Pankaj,
> >
> > While I appreciate the sentiment, I do think its important for
> > me to distinguish when I am giving an opinion as Chair (since
> > I foolishly believe it carries some authority) and when I
> > give a technical opinion that could have come from any individual
> > representing their viewpoint (which I foolishly will carry some
> > technical authority).
> >
> > I actually read an article on how a chair can better perform
> > his/her duties. In addition to announcing on my emails which
> > hat I am wearing, I will actually be buying a Cisco hat
> > and should I choose to comment on something during a meeting
> > I will put the cap on so people do not see the comment as
> > coming from the chair.
> >
> > cheers,
> >
> > mike
> >
> > Pankaj K Jha wrote:
> > >
> > > Mike Takefman wrote:
> > >
> > > > Dave,
> > > >
> > > > (with my cisco hat on)
> > > >
> > >
> > > Mike:
> > >
> > > You are as much of a technical participant as the rest of us are, so I
> > > guess you don't need to keep changing hats (between Cisco & RPR) - it
> > > messes up hair unnecessarily :-)
> > >
> > > We're discussing here as technical individuals; and we all value your
> > > thoughts on issues and truly appreciate your active participation.
> > >
> > > Best regards,
> > > Pankaj
> > >
> > > > 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.