----- Original Message -----
Sent: Wednesday, April 04, 2001 12:49
PM
Subject: RE: [RPRWG] Scheduling
Why not ADAPT Diffserv's well defined scheme.
It has already defined the behaviours for what you are
suggesting.
We need not re-invent and re-define
the traffic characteristics and behaviours again.
Just a thought !
Ashwin
-----Original Message-----
From:
William Dai [mailto:wdai@xxxxxxxxxxxx]
Sent: Wednesday, April 04, 2001 2:49 PM
To: Ray Zeisz
Cc: stds-802-17@xxxxxxxx
Subject: Re: [RPRWG] Scheduling
Actually, I'm a proponent of 3 priorities, i.e.
Class A: Guaranteed provisional BW and low transit delay
and jitter.
Class B: Guaranteed provisional
BW.
Class C: Best Effort
I'm not sure yet about the relationship between 802.1p and
the above
classifications.
William Dai
----- Original Message -----
From:
"Ray Zeisz" <Zeisz@xxxxxxxx>
To: "'William
Dai'" <wdai@xxxxxxxxxxxx>
Sent: Wednesday,
April 04, 2001 11:09 AM
Subject: RE: [RPRWG]
Scheduling
> Thanks for setting me straight. After thinking
about it some more, I
think
> I agree with you. Do you think 2 priorities is
enough? 802.5 and 802.1p
> have 8.
>
>
> Ray Zeisz
> Technology
Advisor
> LVL7 Systems
> http://www.LVL7.com
> (919) 865-2735
>
>
>
>
> -----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
> > > >
> >
> >
> > > >
> >
>
>