RE: [RPRWG] Cut through definition?
All,
Relative to the discussion of cut through, et. al.
My perception is that a cutthrough node has two
insertion buffers, for classA (provisioned synchronous)
and classB (provisioned asynchronous).
The preferred transmit order is as follows:
a) classA insertion buffer (always)
b) classA transmit traffic (subject to provisioned rate)
c) asynchronous traffic.
The classA insertion buffer only needs to be the size of
the maximum packets sent by this node, plus (perhaps) some
extra symbols to deal with hardware decoding latencies.
The classB insertion buffer is to deal with the accumulation
asynchronous packets that occurs when (worst case) full asynchronous
is coming in/out and rate-limited synchronous is being transmitted.
The size of the classB buffer is on the order of several upsteam-link
delays times rateOfSynchronous/rateOfLink ratio.
Order of the asynchronous traffic (c) depends on the classB
buffer-filled status, prenegotiated vs. consumed rates, and
the size of the asynchronous backlog in the client.
The asynchronous transmit buffer is a bit schitzophrenic on its
behavior. It should be in the client (not the MAC) because that
allows packets to be reordered/inserted/deleted until the just
before transmission time. However, the amount of traffic in the
asynchronous transmit queue may influence the MAC queue-selection
and throttle-signal assertion properties.
I personally favor allowing cut-through synchronous traffic to
preempt asynchronous, even in the middle of a packet. That's
yields the lowest possible jitter, but at some encoding complexity
costs.
DVJ
-----Original Message-----
From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
Behalf Of Carey Kloss
Sent: Wednesday, March 28, 2001 8: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
> >
> >
> >