From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Sun Sep 25 2005 - 14:46:15 GMT-3
Thanks for the reply Chris.
So what I"m understanding is that the best way to set this up is to make sure that my fragmentation is set on all affected frame interfaces in the cloud.
And, that fragmentation value should be a reflection of the local access rate. So if a spoke has access rate of 256k, and fragmentation is 10milliseconds, we set fragmentation to 320 bytes. Fair enough.
My concern is when it comes to the hub site that aggregates the spokes.
After reading your post, it makes sense that the fragmentation values are locally significant depending upon the access rate regardless of hub or spoke or what specific DLCI we're using. The only "hole" this leaves in my thoughts is the option to configure the fragmentation on a per-DLCI basis within a map-class frame-relay command.
I'm trying to think of the value to changing the fragmentation values on a per-DLCI basis when multiple DLCI's could exist on the interface. Doing so could actually impair your traffic flow by blowing out your PQ delay budget on one DLCI in favor of another... why I couldn't say.
Andy
________________________________
From: chrlewis@cisco.com [mailto:chrlewis@cisco.com]
Sent: Sat 9/24/2005 6:43 PM
To: Edwards, Andrew M; ccielab@groupstudy.com
Subject: RE: frame fragmentation and the many methods...
Hi,
My practice is always to use the access rate for calculating the
fragment size, as per the answer I gave last week to Quetta. So you
don't have to be concerned with the different DLCI speeds.
Chris
The answer depends on what delay you will accept on that interface
before a voice packet can be transmitted.
The higher the speed on the interface (which is what I always use to
calculate how fast the packet is clocked on to the wire, rather than the
DLCI speed) and the smaller the fragment size, the lower the delay any
PQ packet has to wait before it can be transmitted if a non-PQ fragment
has been sent to the interface Tx-ring ahead of it.
The fragment value is in bytes, so I do it by dividing the access rate
by 8, so if there is a 256K access rate for example, this equates to
32000 bytes per second.
If I only want to allow 10 milliseconds delay for queueing in my design,
I'd set fragment to 320. There are no right answers, just how much of
your delay budget you can llocate to queueing delays at that point in
the network.
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Edwards, Andrew M
Sent: Wednesday, September 21, 2005 7:06 PM
To: ccielab@groupstudy.com
Subject: Re: frame fragmentation and the many methods...
I have a question for GS on this option:
For frame fragmentation to prevent egress blocking we have to enable
fragmentation across all frame links in the cloud that can be affected.
I would like to extend this idea into a hub/spoke partial mesh with the
hub having a second sub interface to another router.
For simplicity sake the hub router is a full T1 and its two spokes are
running at 384 each. The sub interfacace and remote router are at 768.
Easy math... 8)
What I need to understand is how to account for the various rates for
each PVC and how fragmentation needs to be adjusted on a per DLCI basis
to support LLQ.
If this is beyond the scope of R&S lab someone call foul for me and I'll
gladly forget I mentioned it. However, if not, what I'm wondering is if
each PVC requires a fragmentation size that is specific to its local
traffic, or if the fragmentation size should be the same across all the
interfaces....?
I'm thinking its locally significant based upon the priority BW for a
given dlci.
Anyone else have a clue?
Andy
PS. When I first joined this list 2 years ago I thought people who
asked this type of question were just too tweaked! 8) Now I know
better.
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:16 GMT-3