From: Michael Snyder (msnyder@revolutioncomputer.com)
Date: Mon Feb 09 2004 - 00:04:35 GMT-3
Without the math, it makes complete sense that the fragment size should
relate to Bc value. In the real world I probably would use the Bc/8 as
the fragment size.
In the idealized world of the lab, I'm thinking portspeed/8 prorated by
the given delay budget (time budget/1 second).
Thanks for the food for thought.
-----Original Message-----
From: Bob Sinclair [mailto:bsin@cox.net]
Sent: Sunday, February 08, 2004 8:53 PM
To: Michael Snyder
Cc: ccielab@groupstudy.com
Subject: Re: Quick question on Voip over Frame.
Mike,
Recent, authoritative sources all have us calculate the fragment size as
the
number of bytes that can be serialized on a link within a delay budget.
Ten
milliseconds is often used as the acceptable, per-hop delay, so the
fragment
size is usually link speed/8 times .01.
But shouldn't we also consider the shaping parameters? Given the shaped
rate of 32K and the Tc of 10 milliseconds, then it will take two Tc to
transmit our fragment. This does not seem right, but seems in accord
with
every example I have seen.
Perhaps this is an artifact of the very low shaped rate in this example.
But I can certainly see why you might want to consider Bc in your
fragment
size calculation. Especially when Tc is also equal to 10 ms, which is
the
figure normally used as the target maximum serialization delay in the
fragment size calculation.
In other words, maybe the best fragment size for the given scenario
would be
your 320 bits /8 or 40 bytes ???
Should the fragment size, then, be the lesser of the two results -
1 link bw/8 X .01
2 Bc/8 ????
Bob Sinclair
CCIE #10427, CISSP, MCSE
www.netmasterclass.net
----- Original Message -----
From: "Michael Snyder" <msnyder@revolutioncomputer.com>
To: <patrick.basso>
Cc: "'Bob Sinclair'" <bsin@cox.net>
Sent: Sunday, February 08, 2004 9:16 PM
Subject: RE: Quick question on Voip over Frame.
> Thanks Bob, Good catch.
>
> I used the cir speed for my math, and put it into bits.
>
> Double error, glad I'm not playing baseball. :)
>
> Checked the command reference, it's in bytes like you said, the ios
help
> doesn't list it.
>
>
> So it is total bytes per second (port speed/8) times (millisecond
> interval/1000) = fragment size in bytes.
>
>
> -----Original Message-----
> From: Bob Sinclair [mailto:bsin@cox.net]
> Sent: Sunday, February 08, 2004 3:52 PM
> To: Michael Snyder; ccielab@groupstudy.com
> Subject: Re: Quick question on Voip over Frame.
>
> Michael,
>
> Since the frame-relay committed burst, Bc, is in bits and the fragment
> size
> is in bytes, I don't think it would be correct to say that the
fragment
> size
> would equal the Bc.
>
> The Bc should be the number of bytes that can be sent per Tc at the
link
> speed. For a 64000 bps link and a Tc of 10 milliseconds, that would
> be a
> fragment size of 80 bytes.
>
> 64000/8 X .01 = 80 bytes
>
> HTH,
>
> Bob Sinclair
> CCIE #10427, CISSP, MCSE
> www.netmasterclass.net
>
> ----- Original Message -----
> From: "Michael Snyder" <msnyder@revolutioncomputer.com>
> To: <ccielab@groupstudy.com>
> Sent: Sunday, February 08, 2004 4:11 PM
> Subject: Quick question on Voip over Frame.
>
>
> > Using the requirements for Voip
> >
> > Port Speed 64000
> > CIR 32000
> > Tc 10 ms
> >
> >
> > map-class frame-relay voip
> > frame-relay cir 32000
> > frame-relay bc 320
> > frame-relay be 0
> > frame-relay mincir 32000
> > no frame-relay adaptive-shaping
> > frame-relay fragment 320
> >
> >
> > fragment type end-to-end fragment size 320
> > cir 32000 bc 320 be 0 limit 40 interval 10
> > mincir 32000 byte increment 40 BECN response no
> > frags 22 bytes 1561 frags delayed 17 bytes
> delayed
> > 1201
> >
> >
> > 1) Will the fragment size always equal Bc?
> >
> > 2) Should I use the `frame-relay ip rtp priority 16384 16383 32`
with
> my
> > class or add my own priority queue to the physical interface?
> >
> > There's no firm requirements, just trying to figure out a good way
of
> > doing it.
> >
> >
>
http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a
> > 00800d6788.shtml
> >
> >
> > Michael Snyder
> > Lead Network Engineer
> > CCNP/DP, CSS1, MCSE NT/2000
> > Revolution Computer Systems
> > (270) 443-7400
> >
> >
>
This archive was generated by hypermail 2.1.4 : Fri Mar 05 2004 - 07:13:47 GMT-3