RE: FR Fragmentation on the interface

*resent with queue diagrams fixed (hopefully :) )

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Gavin Schokman
Sent: 05 April 2010 23:40
To: ccielab_at_groupstudy.com
Subject: FR Fragmentation on the interface

Evening Brains-Trust,
 
I've dug myself a nice little mental hole in relation to FR
Fragmentation that I could use some help digging myself out of.
The question I've got relates to the "FR Fragmentation at the Interface"
feature, and is based on bits of information from various sources, but 3
mains ones as described below.
Questions follow at the end. (This is an area that I've never really
come to terms with which is why I'm working to clarify all the questions
I have on this topic).
 
Info-scrap #1:
http://blog.ine.com/2008/01/25/link-efficiency-fragmentation/
By my interpretation, the above link indicates that when this feature is
enabled, there are effectively 3 queues at play:
 
[Interface Software Queue] -> [2-level Interleaving queue] -> [Interface
hardware queue]
 
Extending this to include the per-PVC queues, we get
 
[Per-PVC software queue] -> [Interface Software Queue] -> [2-level
Interleaving queue] -> [Interface hardware queue]
 
 
Info-scrap #2:
http://blog.ine.com/2008/01/24/
The above article makes a few statements that are relevant to my
question:
- "Per-PVC software queue" must be CBWFQ (ok, this makes sense)
- Physical interface queue, i.e. "Interface Software Queue", can be any
of WFQ, CQ, PQ or CBWFQ
 
 
Info-scrap #3:
http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_frque_fr
ag_i
f_ps6441_TSD_Products_Configuration_Guide_Chapter.html
 
-- quote
When shaping is configured and traffic exceeds the rate at which the
shaper can send frames, the traffic is queued at the shaping layer using
fair queueing. After a frame passes through the shaper, the frame is
queued at the interface using whatever queueing method is configured. If
shaping is not configured, then queueing occurs only at the interface.
-- end quote

So in my mind, this makes the queues in Info-scrap #1 different
depending on whether traffic-shaping is enabled or not.
 
With traffic-shaping disabled:
 
[Per-PVC software queue] -> [Interface Software Queue] -> [2-level
Interleaving queue] -> [Interface hardware queue]
[CBWFQ ] [WFQ,CQ,PQ or CBWFQ ] [Dual-FIFO]
[FIFO ]
 
 
With traffic-shaping enabled:
 
[Per-PVC software queue] -> [Shaper Queue ] -> [Interface Software
Queue] -> [Interface hardware queue]
[CBWFQ ] [CBTS, GTS or CAR ] [WFQ,CQ,PQ or CBWFQ
] [FIFO ]
 
 
Q1. Is my interpretation and summary of the three documents correct?
1a. are there actually 4-layers of queues involved in the
non-traffic-shaped case? If not, where have I gone wrong?
1b. does the interleaving queue disappear in the traffic-shaped case? If
not, where have I gone wrong?
 
Q2. Are GTS and CAR valid options in the traffic-shaped case?
 
Q3. How does CBWFQ on the Per-PVC software queue map into CQ or PQ on
the Interface queue? (as depicted in the non-traffic-shaped case)
 
Hopefully someone can help me work this out once and for all.
Many thanks.
 
Cheers,
Gavin

Blogs and organic groups at http://www.ccie.net
Received on Tue Apr 06 2010 - 00:49:26 ART