----- Original Message -----
Sent: Wednesday, April 04, 2001 1:02
PM
Subject: RE: [RPRWG] Scheduling
Dai,
You are right on that, such procedures should be implemented
above the MAC.
But the essense of Ray's message (I
Beleive) was that we can use store-and-forward mechansms without any ring
access protocol's in the MAC.
What are the disadvantages of this approach. Can't we getway
without a ring access protocol in the MAC.
Can anyone provide reasons other than LATENCY "whereby each
frame is completely received and verified before being placed on the next hop
of the ring"
I am not an expert on this (LATENCY), but is this a concern
when vendors are claiming line-speed layer 1-7 switching/routing.
Thanks
Ashwin
-----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
> > >
> > >
> > >
>