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
>