| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Necdet/Gary:
I referenced the draft you linked below, I then search for "CIR/EIR/BIR" and it was referenced in section 2.2.2 Under the title "Medium Priority Service". This reference still implies TCP reordering.
Mike:
Can you shed some light on this.
Thank you,
Joseph Cordero
-----Original Message-----
From: Necdet Uzun [mailto:nuzun@xxxxxxxxx]
Sent: Friday, December 21, 2001 7:17 PM
To: Turner, Gary (Gary)
Cc: 'Mike Takefman '; 'Anoop Ghanwani'; 'stds-802-17@xxxxxxxx '
Subject: Re: [RPRWG] Frame reordering for medium priority traffic in
Gandalf?
Gary,
I was not able to find the part that you are referring to in the Gandalf draft.
Are you sure that you are accessing
http://grouper.ieee.org/groups/802/17/documents/drafts/gandalf_04Plus.pdf.
Thanks.
Necdet
"Turner, Gary (Gary)" wrote:
> Mike, Anoop, Jim,
>
> Unfortunately, the revised text still says:
>
> "However the priority class on the ring transit
> path will be different depending on whether the
> particular frame is in or out of its agreed
> CIR/EIR/BIR profile."
>
> This would still lead to misordering.
>
> Looking at other parts of the proposal, in particular
> the flowchart of Fig. 12 on page 39 I think the profile
> conformance only affects access to the ring: during
> the time of conformance Med packets are added just
> behind Hi packets in priority, but during the time of
> nonconformance they are added subject to the
> fairness algorithm, just ahead of Lo traffic.
>
> Once on the ring Med traffic always occupies the Lo
> transit queue.
>
> Is this correct?
>
> Thanks,
>
> Gary Turner
>
> > ----------
> > From: Anoop Ghanwani[SMTP:anoop@xxxxxxxxxxxxxx]
> > Sent: Friday, December 07, 2001 1:01 AM
> > To: 'Mike Takefman '; Anoop Ghanwani
> > Cc: 'stds-802-17@xxxxxxxx '
> > Subject: RE: [RPRWG] Frame reordering for medium priority traffic in
> > Ganda lf?
> >
> >
> >
> > Mike,
> >
> > And in fact the pre-Gandalf proposal did actually state
> > things the way you explain below. That's what confused
> > me. Thanks for the clarification.
> >
> > -Anoop
> >
> > -----Original Message-----
> > From: Mike Takefman
> > To: Anoop Ghanwani
> > Cc: stds-802-17@xxxxxxxx
> > Sent: 12/6/01 8:24 PM
> > Subject: Re: [RPRWG] Frame reordering for medium priority traffic in
> > Gandalf?
> >
> > Anoop,
> >
> > We discovered this error in the document soon after the meeting.
> > Our presentations have consistently stated that the medium
> > priority class is treated as high priority only from the
> > perspective of admission, not transit. Clearly, we missed it
> > in our review of the document prior to the meeting.
> >
> > thank you for raising the issue,
> >
> > mike
> >
> > Anoop Ghanwani wrote:
> > >
> > > In Section 2.2.2 of the Gandalf proposal, we have the following
> > > statement:
> > > "However the priority class on the ring transit path will be
> > > different depending on whether the particular frame is in or
> > > out of its agreed CIR/EIR/BIR profile. In-profile frame will
> > > be delivered on the high priority low-delay transit path while
> > > out-of-profile traffic will transit on the low-priority,
> > > best-effort path."
> > >
> > > This seems to suggest that frames belonging to the medium
> > > priority class of traffic can get reordered since a later
> > > frame that is determined to be in-profile may get to
> > > the destination node before an earlier one that was
> > > determined to be out-of-profile.
> > >
> > > It's well known that protocols such as TCP will suffer
> > > throughput degradation if packets are reordered, and
> > > therefore most protocols (such as, for example, 802.3ad
> > > link aggregation) make every effort to ensure that frames
> > > are delivered to the destination in order. Is there a
> > > reason why re-ordering has been considered acceptable in
> > > this case?
> > >
> > > This issue may have already been brought up at the meeting,
> > > but if it was then I missed it. (I must've been at one
> > > of them bridging sessions. :-)).
> > >
> > > -Anoop
> >
> > --
> > Michael Takefman tak@xxxxxxxxx
> > Manager of Engineering, Cisco Systems
> > Chair IEEE 802.17 Stds WG
> > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > voice: 613-254-3399 fax: 613-254-4867
> >
- - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.