----- Original Message -----
Sent: Friday, March 30, 2001 12:10
PM
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
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