| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Back to the cut-through (CT) versus store and forward (SaF) discussion:
For a RPR, when I say cut through it is not at soon as the first bit is received
on the ring.
There are certain header fields (TBD) that need to be check.
If we want to add a header checker then the entire header will have to be validated.
Header checking is good because it guaranteed that a packet with a corrupted DA
will not stay on the ring until its TTL expires.
Although I call it cut through, I mean that at least the header is validated.
It the packet is not for the client at the current node, it is send to the pass through (PT) buffer.
The scheduler or arbiter then check if a add packet is being sent.
If there is no add packet, the tandem packet can then operate in the
traditional cut-through mode.
Store and forward means at the ring input, the entire packet is received and buffered before
it is forward to the PT buffer. This allows errored tandem packet to be discarded.
The advantage of cut-through becomes more important for ring rates running at OC-3 (or lower).
The tandem delay is not one MTU due to add packet blocking the tandem but 2x (in the worst case).
One for store and forward and one for the arbiter. For high ring data rate, this is a
moot point.
Regards,
Harry
The other cut-though and store and forward topic mentioned is more of a congestion management, avoidance, and fairness as Offer pointed out. This is a fairness issue and how you handle different classes of traffic on the ring . This is a separate topic that deserves its own discussion.
-----Original Message-----
From: Offer Pazy [mailto:pazy@xxxxxxxxxxxxxxxxxx]
Sent: Friday, March 30, 2001 1:53 PM
To: 'Carey Kloss'; 'Devendra Tripathi'
Cc: stds-802-17
Subject: RE: [RPRWG] Cut through definition?
Carey,
In an attempt to define CUT-Thru you are really confusing two, completely
separate, time-scales: The immediate one, in which we are concerned with
cut-thru Vs store and forward, and another time scale (called differently,
the RTT time or the control time) in which we deal with congestion
avoidance, BW management, fairness and all these beauties. These two time
scales are fairly independent with one exception: If you can analyze your
control protocol up to a single packet-time, then you may reason about the
behavior in the immediate time scale. Usually this is not a very useful
exercise, since the HW design which accommodates this time scale has to
worry about worst case anyhow.
Personally, I can't get too excited about the argument S&F VS CT. I really
believe it is immaterial. Since there will always be cases (in whatever
approach we choose) where you will have to block transit traffic (this
happens where the "added" frame is begun transmission, and I exclude
fragmentation), then the real questions we have to answer are:
- Arbitration rules
- Size of buffers (just to clarify, this size may start at 1 bit).
Then the religious war about S&F Vs. CT becomes moot.
Offer Pazy
Sr. Product Manager
Native Networks
15 Gonen St.
Petah Tikva 49170
Israel
Tel: +972 3 921-0010 Ext. 229
Fax: +972 3 921-0080
pazy@xxxxxxxxxxxxxxxxxx <mailto:pazy@xxxxxxxxxxxxxxxxxx>
http://www.nativenetworks.com
The Native Way = Ethernet Simplicity + SONET Reliability
-----Original Message-----
From: owner-stds-802-17@xxxxxxxx [mailto:owner-stds-802-17@xxxxxxxx]On
Behalf Of Carey Kloss
Sent: Thursday, March 29, 2001 06:54
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
> >
> >
> >