| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Shaping and then scheduling is nonwork conserving scheduling scheme. The fact that you are shaping means that you willmake packets wait in buffer till it conforms to the shaper rate and burst size even though in the mean time output link is available for transmission. This will leave output link less utilized than in non shaped scheme where you send at the first opportunity.-Sanjay K. Agrawal-----Original Message-----
From: Adisak Mekkittikul [mailto:adisak@xxxxxxxxxxxxxx]
Sent: Friday, March 30, 2001 1:38 PM
To: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Cut through definition?Sanjay,Can you elaborate on why the shaper would let the link go idle for a short period of time? I have not seen this problemon any of the shaper implementations I have come across.Adisak-----Original Message-----
From: Sanjay Agrawal [mailto:sanjay@xxxxxxxxxxxx]
Sent: Friday, March 30, 2001 12:10 PM
To: 'Adisak Mekkittikul'; stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Cut through definition?Hi Adisak,
Even if you shape the traffic which means for short periord of time you will let link go idle, I think traffic will become bursty around the ring, unless you provide shaping in the RPR mac which requires buffering.
Burstyness is not a property of Class based scheduling. Traffic is policed (and shaped) before it is aggregated in the class queues. You control the bw provisioning and burstyness
at the customer ports. Once aggregated into classes, you only maintain class based aggregates around the ring.
The case you pointed out was for dynamic SLA's where customer burst's twice his bw and goes quiet for an hour. Again taking the extreme approach you could choose to sell 1 hour long burst size in the over committed class, this way all the higher priority traffic (committed traffic, delay sensitive committed) would not suffer, only other over committed traffic will suffer, which should be expected.
In addition, you may have many SLA's (1000's to millions) around the ring point to point and point to multipoint. I see class based priority scheduling as the only solution for scalability of these SLA's, and simplicity of MACs.-Sanjay K. Agrawal
-----Original Message-----
From: Adisak Mekkittikul [mailto:adisak@xxxxxxxxxxxxxx]
Sent: Thursday, March 29, 2001 1:59 PM
To: stds-802-17@xxxxxxxx
Subject: RE: [RPRWG] Cut through definition?
Carey,
I'm very glad that you brought up the issue of goodput vs. SLA. It's our
view
that one customer's QoS should not suffer for another customer's goodput.
A customer's SLA typically includes burst parameters that specify how much
the
customer is allowed to burst over his or her committed rate. This burst
needs
to be absorbed by the line card, and should not be propagated to the ring
where
it could adversely affect other customers who conform to their SLA contract.
In other words, we don't believe that strict priority is the right solution
for
SLA-based public networks. Imagine, one customer wants to burst twice his
SLA
rate (10G) for 1 hour and then go quiet for the next hour. Had we let his
traffic
on the ring, other customers wouldn't get any BW for one hour! Although this
is
an extreme example, it illustrates that maximize goodput alone is not a
sound
policy for a shared public networks.Delay and jitter must be taken into consideration while RPR flow control
attempts
to maximize goodput.
Adisak
-----Original Message-----
From: Carey Kloss [mailto:ckloss@xxxxxxxxxxxxxxxx]
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 QuestionMy 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