From: Scott Morris (swm@emanon.com)
Date: Tue Nov 01 2005 - 11:50:14 GMT-3
Be careful in "how odd" you're trying to make things! While the CCIE
sccenarios aren't exactly "normal" they aren't that bad either!
If something says to configure fragmentation so that "voice packets are not
fragmented" that simply means your fragment size needs to be bigger than the
size of a voice packet. VoIP packets will be about 200-220 bytes in size as
I recall. So any fragment size bigger than that will not fragment voice.
Usually we look to fragment though because of latency issues, not size
issues.
You can figure out how long it takes to serialize a packet by dividing the
packet size by the speed of the line. If you have a 1500 byte packet (1500
* 8 to get bits) and can put information on a link at 128000 bits per
second, how long will it take you to get that 1500 byte packet out of the
way?
If you have fragmentation on your lab (IMHO) it would be a bit more
straightforward in that they would tell you that it's been determined the
optimal efficiency of the link is when no packet takes up more than 512
bytes or something like that. It's already mis-named since we deal in
frames (not packets) at Layer 2 links, but there are a couple things then.
You could change your MTU size to 512, although that may mess up many
applications that say don't fragment at L3. or you could employ FRF.12
fragmentation at L2 with the size of 512 bytes. Not that we would need to
worry about the math or the why they picked that, just that they told you
what needed to be done and you need to implement it.
Don't make things harder than they already are! :)
Scott
-----Original Message-----
From: Ralph [mailto:Mandela@myrealbox.com]
Sent: Tuesday, November 01, 2005 8:13 AM
To: swm@emanon.com
Cc: imal.kalutotage@gmail.com; DSchulz@dpsciences.com;
ccielab@groupstudy.com
Subject: Re: RE: RE: Re: Frame-Relay fragmentation
Thanks for the clarification Scott. Makes a lot of sense to me. Is it
recommended to use the voice design guidelines to configure the fragment
size in a CCIE Lab scenario, if a specific value is not given? If the CIR is
above 768K, and the question ask to configure fragmentation so that voice
traffic are not fragmented, what would be a recommended approach? It seems
that CCIE lab questions do not often times mirror real life scenarios, there
is always this issue of conflict between design guidelnes or best practices
and what the lab is testing for (whatever!)
Many Thanks
Ralph
-----Original Message-----
From: "Scott Morris" <swm@emanon.com>
To: "'Imal kalutotage'" <imal.kalutotage@gmail.com>, "'Ralph'"
<Mandela@myrealbox.com>
Date: Tue, 1 Nov 2005 00:29:40 -0500
Subject: RE: RE: Re: Frame-Relay fragmentation
Fragment size is not necessarily tied to the Bc. Let me back up a bit
here... It's not tied to Bc in as much as a particular calculation that you
will do. It should be taken into account mathematically because it doesn't
make any sense to have a large burst but small fragment size.
However, since you fragment based on the latency issues you may experience
(serialization delay as a predictable one) and want to make things smaller
so that your voice traffic has a fair chance on the line, then it would
stand to reason that your calculation be based on the serialization speed
with regards to a timing of a packet rather than the exact size.
At least that's how FRF12 takes things into account. It looks for a packet
size that you want. A good guideline (you can always check with the various
voice design guides) is 80 bytes per 64K line speed. So if you have a 128K
line, your fragment size would be 160. If you have a 512K line, it would be
640.
At the same time, when you are calculating your shaping stuff, since we're
doing this with voice in mind, it would stand to reason that you pick 10ms
as your sample size, and therefore if shaping to 64K your Bc would be 640
bits (fragment size is in bytes, so while the numbers are the same here,
they don't really have a lot to do with each other).
Typically, you do not fragment on links that have speeds above 768K. The
reason isn't that serialization delay disappears, but more because it'll
take you more time to process through the fragmentation then it would to get
the stuff out on the line anyway.
Regardless of this logic, if the lab gives you specific values, you do
whatever they want! :)
I hope this has cleared things up a little bit and not added to the
confusion.
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Imal
kalutotage
Sent: Tuesday, November 01, 2005 12:17 AM
To: Ralph
Cc: DSchulz@dpsciences.com; ccielab@groupstudy.com
Subject: Re: RE: Re: Frame-Relay fragmentation
Hi,
can somebody tell me how to calculate fragment size from the Bc..
Cheers
imal
On 11/1/05, Ralph <Mandela@myrealbox.com> wrote:
>
> Dave,
>
> The CiscoPress Book "IP Quality of Service" by Srinivas Vegesna, Has a
> good explanation and case study on frame-relay fragmentation. IMHO, I
> think this book does a good job explaining a lot of QoS topics.
>
> Ralph
>
> -----Original Message-----
> From: "Schulz, Dave" <DSchulz@dpsciences.com>
> To: "Ralph" <Mandela@myrealbox.com>
> Date: Mon, 31 Oct 2005 21:59:53 -0500
> Subject: RE: Re: Frame-Relay fragmentation
>
> Thanks for the great info, Ralph. Do you have any recommendations on
> the technical details of fragmentation. The doc CD is somewhat limited
> on this subject. Yes, fragmentation is fair game. Even though voice is
> not a part of the R&S exam, surely having the router/switch prepared
> for this, would be a viable test option.
>
>
> Dave Schulz,
> Email: dschulz@dpsciences.com
>
>
> -----Original Message-----
> From: Ralph [mailto:Mandela@myrealbox.com]
> Sent: Monday, October 31, 2005 7:36 PM
> Cc: Schulz, Dave; ccielab@groupstudy.com
> Subject: Re: Re: Frame-Relay fragmentation
>
> Dave:
>
> Using a Tc of 10ms is good for voice latency. Calculate the fragment
> size from the Bc value. If its greater than the average size of VOIP
> packets, VOIP should be transmitted unfragmented.
>
> HTH
> Ralph
>
> -----Original Message-----
> From: "Ralph" <Mandela@myrealbox.com>
> To: DSchulz@dpsciences.com
> Date: Mon, 31 Oct 2005 18:48:24 -0500
> Subject: Re: Frame-Relay fragmentation
>
> Hello Dave:
>
> FRF.12 does not discriminate betweeen voice and data. Particularly if
> it's VOIP (layer 3)and fragmentation being layer 2. If the fragment
> size is less than the average size of the VOIP packets they will all
> be fragmented. If the VOIP packets are less than the fragment size,
> just like any other type packet, they will be transmitted without
> being fragmented.
>
> On the other hand, FRF.11C does discriminate between voice and data.
> It does not fragment voice packets regardless of what fragmentation
> size is configured. But if I can recollect properly, FRF.11C is used
> only on DLCIs configured for VoFR, (layer 2). However, this form of
> fragmentation is not recommended for VOIP.
>
> As for the configuration of FRF.12, all you really need is the
> map-class frame-relay fragment command. It's also commonly used with
> the map-class frame-relay fair queue command; Probably can also be
> used with the map-class priority-group command - not very certain.
> After all fragmentation actually occurs at the TxQ.
>
> With Voice not being tested anymore in the Lab, do you think frame
> relay fragmentation is still something to be concerned with?
>
> HTH
> Ralph.
>
>
>
>
>
>
> -----Original Message-----
> From: "Schulz, Dave" <DSchulz@dpsciences.com>
> To: <ccielab@groupstudy.com>
> Date: Mon, 31 Oct 2005 17:04:56 -0500
> Subject: Frame-Relay fragmentation
>
> I was working through the doc CD, where it stated something about the
> FRF.12 inherently allows all voice traffic to pass-through
> unfragmented, while fragmenting the data packets to the specific
> length. So, can I assume that if a lab states to fragment all packets
> above 53 bytes (the default), and allow voice to be
> unfragmented....then you may simply configure "frame-relay fragment"
> command under the specific frame map-class or interface, along with
> the frame-relay traffic-shaping interface command?
>
> I almost want to believe that priority queuing is needed, but am
> confused on which way to go here (sometimes we make things more
> complicated then they really are). Thoughts?
>
>
> Dave Schulz,
> Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com >
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:04 GMT-3