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
> >
> >
> >