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