Re: [RPRWG] Cut through definition?
Bora,
If you think CSMA/CD based "shared media" network is good enough for
the QoS to be handled only by upper layers, then you are right.
William Dai
----- Original Message -----
From: "Bora Akyol" <akyol@xxxxxxxxxx>
To: "William Dai" <wdai@xxxxxxxxxxxx>
Cc: <stds-802-17@xxxxxxxx>
Sent: Friday, March 30, 2001 11:10 PM
Subject: Re: [RPRWG] Cut through definition?
> Two comments (from an IP/MPLS person):
>
> 1) Let the upper layers deal with the QoS and prioritization. Keep the
> channel simple and efficient. (See the lack of use on 100B-VG, 802.1p)
> Most routers today have really accurate and wire rate QOS forwarding
> capabilities.
>
> 2) IP and MPLS work best with store and forward architectures.
>
> Ethernet like MAC or token ring highly recommended.
>
> But I guess this would not provide enough job security :-)
>
> Bora
>
> On Friday, March 30, 2001, at 02:14 PM, William Dai wrote:
>
> > I totally agree with Sanjay's point regarding QoS issue, though this
> > thread of discussion
> > has nothing to do with Cut-through definition.
> >
> > I want to narrow the scope down to the MAC layer. The strict
> > priority gives high priority
> > class low delay media access, but it could be abused by system design.
> > So for the
> > interoperability, some sort of shaping or throttling mechanism for the
> > traffic flow from
> > system layer to the MAC layer also needs to be standardized. System
> > designers could
> > add value in the system layer, but the MAC layer should be forced to
> > behave on the RPR
> > ring.
> >
> > William Dai
> >
> > ----- Original Message -----
> > From: Sanjay Agrawal
> > To: 'Adisak Mekkittikul' ; stds-802-17@xxxxxxxx
> > Sent: Friday, March 30, 2001 12:10 PM
> > Subject: RE: [RPRWG] Cut through definition?
> >
> > Hi Adisak,
> >
> > Even if you shape the traffic which means for short periord of time you
> > will let link go idle, I think traffic will become bursty around the
> > ring, unless you provide shaping in the RPR mac which requires
> > buffering.
> >
> > Burstyness is not a property of Class based scheduling. Traffic is
> > policed (and shaped) before it is aggregated in the class queues. You
> > control the bw provisioning and burstyness
> >
> > at the customer ports. Once aggregated into classes, you only maintain
> > class based aggregates around the ring.
> >
> > The case you pointed out was for dynamic SLA's where customer burst's
> > twice his bw and goes quiet for an hour. Again taking the extreme
> > approach you could choose to sell 1 hour long burst size in the over
> > committed class, this way all the higher priority traffic (committed
> > traffic, delay sensitive committed) would not suffer, only other over
> > committed traffic will suffer, which should be expected.
> >
> >
> > In addition, you may have many SLA's (1000's to millions) around the
> > ring point to point and point to multipoint. I see class based priority
> > scheduling as the only solution for scalability of these SLA's, and
> > simplicity of MACs.
> >
> > -Sanjay K. Agrawal
> >
> >
> >
> > -----Original Message-----
> > From: Adisak Mekkittikul [mailto:adisak@xxxxxxxxxxxxxx]
> > Sent: Thursday, March 29, 2001 1:59 PM
> > To: stds-802-17@xxxxxxxx
> > Subject: RE: [RPRWG] Cut through definition?
> >
> >
> >
> >
> > Carey,
> >
> > I'm very glad that you brought up the issue of goodput vs. SLA. It's our
> > view
> > that one customer's QoS should not suffer for another customer's
> > goodput.
> > A customer's SLA typically includes burst parameters that specify how
> > much
> > the
> > customer is allowed to burst over his or her committed rate. This burst
> > needs
> > to be absorbed by the line card, and should not be propagated to the
> > ring
> > where
> > it could adversely affect other customers who conform to their SLA
> > contract.
> >
> >
> > In other words, we don't believe that strict priority is the right
> > solution
> > for
> > SLA-based public networks. Imagine, one customer wants to burst twice
> > his
> > SLA
> > rate (10G) for 1 hour and then go quiet for the next hour. Had we let
> > his
> > traffic
> > on the ring, other customers wouldn't get any BW for one hour! Although
> > this
> > is
> > an extreme example, it illustrates that maximize goodput alone is not a
> > sound
> > policy for a shared public networks.
> >
> > Delay and jitter must be taken into consideration while RPR flow control
> > attempts
> > to maximize goodput.
> >
> >
> > Adisak
> >
> >
> >
> >
> > -----Original Message-----
> > From: Carey Kloss [mailto:ckloss@xxxxxxxxxxxxxxxx]
> > 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
> >
>