From: Victor Cappuccio (cvictor@protokolgroup.com)
Date: Tue Nov 01 2005 - 03:08:33 GMT-3
Scott thanks for the Clarifications, also remember the defaults when turning
on frame-relay traffic-shaping
----- Original Message -----
From: "Scott Morris" <swm@emanon.com>
To: "'Imal kalutotage'" <imal.kalutotage@gmail.com>; "'Ralph'"
<Mandela@myrealbox.com>
Cc: <DSchulz@dpsciences.com>; <ccielab@groupstudy.com>
Sent: Tuesday, November 01, 2005 1:29 AM
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
>
> _______________________________________________________________________
> 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