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