| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dai,
You are right on that, such procedures should be implemented above the MAC.
But the essense of Ray's message (I Beleive) was that we can use store-and-forward mechansms without any ring access protocol's in the MAC.
What are the disadvantages of this approach. Can't we getway without a ring access protocol in the MAC.
Can anyone provide reasons other than LATENCY "whereby each frame is completely received and verified before being placed on the next hop of the ring"
I am not an expert on this (LATENCY), but is this a concern when vendors are claiming line-speed layer 1-7 switching/routing.
Thanks
Ashwin
-----Original Message-----
From: William Dai [mailto:wdai@xxxxxxxxxxxx]
Sent: Wednesday, April 04, 2001 2:16 PM
To: stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] Scheduling
Ray,
Without going into details, the "statistical scheduling", in my mind,
should belong to the layer above the RPR MAC layer, the MAC layer
should provide "fast lane / slow lane" type of service which is
provisionalbe
from upper layers. In this sense, there is nothing wrong with strict
priority
mechanisms in MAC layer, and schemes like WRR, RED should definitely
belong to upper layer.
By the way, packet reordering between different priority, also in my mind,
SHOULD BE allowed, and jitter should not be of concern for low priority
traffic.
William Dai
----- Original Message -----
From: "Ray Zeisz" <Zeisz@xxxxxxxx>
To: "Carey Kloss" <ckloss@xxxxxxxxxxxxxxxx>; "Devendra Tripathi"
<tripathi@xxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Wednesday, April 04, 2001 6:53 AM
Subject: RE: [RPRWG] Scheduling
>
> I am not sure, but it appears that all the proposals are using a strict
> priority mechanism. It seems like everyone wants to give an order in
which
> the queues are emptied. Maybe I am missing something, but wouldn't it be
> better if we could statistically schedule between the transit buffers and
> the transmit buffers.
>
> Has anyone proposed a statistical allocation of bandwidth at each ring
node?
> For example, I can envision a protocol whereby each of the ring
participants
> advertise 1)Their required minimum guaranteed bandwidth and 2)Their
desired
> maximum bandwidth. From these number each ring member could create
> statistical queue weights for the following:
> 1. This node's HP Transmit Buffer
> 2. This node's LP Transmit Buffer
> 3. This node's Transit Buffer
>
> Of course, MAC frames (for a lack of a better term) would always be
> transmitted immediately in front of all user data frames.
>
> In my mind, having multiple transit buffers is a bad thing. Am I missing
> something? Each node should NOT be able to re-order packets based on
> priority, while the packets are "passing through" the node. Doing so
seems
> to create a lot of jitter for the low priority packets; at each node, the
> higher priority packets would be advancing in front of the lower priority
> packets, at least when there is also a packet insertion taking place.
>
> So back to the protocol....by assigning a weight to each of the queues,
you
> assign a probability of transmitting the next packet from either a) the
> ingress from the ring (i.e. transit buffer) or b) this node's locally
> generated traffic.
> Always allowing the transit buffer to have priority prevents the ability
to
> deliver QoS in light of the fact that there could be a misbehaving node
> somewhere on the ring. However, if all of the nodes can agree on their
> respective probabilities to transmit, and if this probability can be
applied
> to the queues, we should be able to support many priorities as well as
> provide the ability to utilize 100% of the bandwidth regardless of the
> priority profile of the traffic. Something that a strict reservation of
> bandwidth would not support.
>
> One other thing to note...in my mind, and in this note, all nodes are in
> store-and-forward mode, whereby each frame is completely and totally
> received and verified before being placed on the next hop of the ring.
>
> Please feel free to point out any mistakes in my logic, I am new to
802.17,
> but I look forward to meeting you at the next meeting.
>
> Ray Zeisz
> Technology Advisor
> LVL7 Systems
> http://www.LVL7.com
> (919) 865-2735
>
>
>
>
> -----Original Message-----
> From: Carey Kloss [mailto:ckloss@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, March 28, 2001 11:54 PM
> To: Devendra Tripathi
> Cc: stds-802-17@xxxxxxxx
> Subject: Re: [RPRWG] Cut through definition?
>
>
>
> I hadn't originally included store and forward congestion control schemes,
> but someone has asked that I add them, to make the discussion more
complete.
> So here are the 2 store and forward schemes that I know:
>
> 1. SRP: Incoming transit traffic is stored in 2 queues, a large low
priority
> queue (512 KB), and a smaller high priority queue (3MTU). If there is no
> congestion, traffic leaves a node in this order: Usage pkt, HP transit,
> other
> control pkts, HP transmit, LP transmit, LP transit. If the node is
congested
> (LP transit buffer crosses a threshold), traffic leaves a node in this
> order:
> Usage pkt, HP transit, other control pkts, HP transmit, LP transit, LP
> transmit. Also, periodically, a node will pass a "usage" message to it's
> upstream neighbor. The usage value is basically the bandwidth of transmit
LP
> traffic that it has been able to send. If the upstream neighbor sees that
> it's current usage is greater than the downstream node, it throttles it's
LP
> transmit traffic. If that upstream node is also congested, it forwards the
> minimum of the two usages (received usage value and its own usage value)
> further upstream.
>
> 2. Luminous: HP transit traffic is stored in an internal transit buffer
and
> all LP traffic is forwarded to the Host at each node. MAC serves the HP
> transit traffic first, whenever the link is idle the host is let to decide
> what to send downstream next.
>
> In the cut through case, I believe that control packets have the highest
> priority over any data packet.
>
> Thanks,
> --Carey Kloss
>
> Devendra Tripathi wrote:
>
> > What about Ring control packets ? Are they given same priority as
transit
> > packet or
> > there is one more priority level ?
> >
> > 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 Carey Kloss
> > > Sent: Wednesday, March 28, 2001 6:07 PM
> > > To: stds-802-17@xxxxxxxx
> > > Subject: [RPRWG] Cut through definition?
> > >
> > >
> > >
> > > I would like to revisit the cut-through vs. store and forward, if
nobody
> > > objects?
> > >
> > > The last discussion ended with a wish to get a more concrete
definition
> > > of cut-through. Towards that end, I would like to put out my own
> > > understanding, and generate feedback on what's specifically different
in
> > > current schemes:
> > >
> > > >From what I understand, cut-through exists as Sanjay has explained
it:
> > > 1. Transit (pass-thru) traffic always has priority over transmit
> > > (add-on) traffic, regardless of class.
> > > 2. There is a small (1-2 MTU) transit buffer to hold incoming transit
> > > traffic when sending transmit traffic.
> > > 3. All prioritization happens at a higher layer, when deciding what to
> > > transmit.
> > >
> > > I was also wondering if there is any agreement on cut-through
congestion
> > > control mechanisms? Looking through the presentations on the RPR
> > > website, I've seen a number of schemes, and this is my understanding
> > > from the slides. Please correct me if I've misunderstood:
> > >
> > > 1. The simplest, local fairness, which I'm not sure that anyone is
> > > implementing: When HOL timer times out for high-pri traffic, send a
> > > congestion packet upstream. This will stall the upstream neighbor from
> > > sending low-pri traffic (after some delay).
> > >
> > > 2. Fujitsu: Keep a cache of the most active source nodes. If a node
has
> > > an HOL timer time out, it sends a unicast "pause" message to throttle
> > > the most active source for a time. After another timeout, it will send
> > > more "pause" messages to other sources. This can be extended to cover
> > > multiple priorities, although I didn't see it explicitly stated in the
> > > slides.
> > >
> > > 3. Nortel, iPT-CAP: When an HOL timer expires, the node calculates
the
> > > number of sources sending through the congested link, and apportions
the
> > > link fairly (if the link is 150M, and there are 3 sources, it decides
> > > that each souce can use 50M). To do this, it sets its B/W cap to 50M,
> > > and then sends a message upstream to tell other nodes to start sending
> > > at only 50M. Once the affected link becomes uncongested, new messages
> > > are sent upstream, advising that more B/W is now available. This will
> > > converge to a fair B/W allocation.
> > >
> > > 4. Dynarc: Token passing and credits. No detailed description. What is
> > > the "goodput"?
> > >
> > > 5. Lantern: Per-SLA weighted fairness, with remaining bandwidth
> > > apportioned fairly to SLAs. There wasn't a good explanation of
> > > congestion handling, though. If the per-SLA rate limits are strictly
> > > enforced to stop congestion, and traffic is bursty, what happens to
the
> > > "goodput"?
> > >
> > > Thanks a lot,
> > > --Carey Kloss
> > >
> > >
> > > Sanjay Agrawal wrote:
> > >
> > >
> > > Please see comments inline.
> > >
> > > -Sanjay
> > >
> > > -----Original Message-----
> > > From: William Dai [mailto:wdai@xxxxxxxxxxxx]
> > > Sent: Thursday, March 22, 2001 2:37 PM
> > > To: Sanjay Agrawal; 'Devendra Tripathi'; Ajay Sahai; Ray Zeisz
> > > Cc: stds-802-17@xxxxxxxx
> > > Subject: Re: [RPRWG] MAC Question
> > >
> > > My understanding of the cut-through definition in Sanjay's
> > > example is
> > > 1. Pass-through packet is allowed to transmit before it is
> > > completely received.
> > >
> > > [Sanjay Agarwal]
> > > Not necessarily. You have same result if you forward packet
> > > after you completely receive it or you start
> > > transmitting before you receive. In the formar case you have
one
> > > packet delay, in latter you don't. 1500byte at 10
> > > gig gives you 1.2 microseconds.
> > >
> > > 2. There is only one transit buffer (regardless of
> > > class).
> > > [Sanjay Agarwal]
> > > Yes that is what proposed cut through schemes have. If you
> > > have multiple classes of service and you allow
> > > priority than you have to arbitrate between add and pass
classes
> > > of traffic at that moment it becomes store and
> > > forward.
> > >
> > > 3. Scheduling Algorithm always give pass-through traffic
> > > (regardlesss of class)
> > > preference over add-on traffic.
> > > [Sanjay Agarwal]
> > >
> > > Yes that is what proposed cut through schemes have. If you
> > > don't give pass higher priority than you don't have
> > > cut through scheme.
> > > which somewhat contradicts with his first statement. Thus the
> > > interesting results.
> > > No. it doesn't.
> > >
> > > The debate should be based on a solid definition of
cut-through
> > > transmission, otherwise
> > > there will be no convergence at the end of the discussion.
> > >
> > > I agree.
> > >
> > > I fully agree Sanjay's first statement, but want to add that
> > > each class should have its
> > > own transit buffer, (personally I prefer having 3 classes
> > > supported as RPR MAC services).
> > > Whether each transit buffer should reside in MAC layer or
> > > systemlayer is up to further
> > > discussion. Under this context, Circuit Emulation (or some may
> > > prefer to call it
> > > Synchronous) class will benefit from the cut-through transit.
> > > [Sanjay Agarwal]
> > > I don't agree in the present cut through proposals case.
> > > Unless you want to define cut though differently.
> > > Ideally it could further benefit from preemptive
> > > transmission (yet another definition to be solidly defined).
> > >
> > > William Dai
> > >
> > >
> > >
>