Eric, I wanted to follow up on this one. I've done a bit of reading since my
original post and your response. I do not have access to the original Frame
Relay Forum FRF.12 document ( alas, it costs 60 bucks, and I have hungry
teenage boys to feed :-<  )

Now if I understand what I read, both in Gil Held's and Elliott Lewis'
excellent books, along with the material I can find at www.frforum.com, the
FRF.12 standard provides a means for "normalizing" ( if you will ) packet
flow across frame relay by fragmenting large, usually data, packets into
smaller sizes, so that small voice packets are better able to flow across
the WAN, without being delayed by large data packets.  FRF.12 provides the
mechanism for interleaving voice and data packets, so that 1) voice packets
are regularly sent. one voice packet, one data packet, one voice packet, etc
and 2) the data packets may still be slightly larger than the voice packets.
Yes, this is different than changing the MTU, but both techniques, it would
seem to this observer, effectively result in the same thing - smaller data
packets so that vocie traffic does not suffer as a result of data traffic
across the same device.

I suppose this harkens back to the inherent divergent interests of voice and
data people. There is a discussion over on the NANOG list ( ongoing for
several days now ) regarding the desire for larger than 1500 byte MTU's on
core switches. Much larger. Yet throughout Held's book, I keep seeing the
concern expressed regarding large data packets. We also had a discussion
here on groupstudy a few weeks back about why the ATM cell size is 48 bytes.
Answer - a compromise between the voice side who wanted 32 byte cells and
the data side who wanted 96 byte cells ( if memory serves )

To get back to my report as to what a particular instructor said in class,
yes, he stated that in projects he had worked on, one way he solved problems
caused by large data packets delaying small voice packets was  to change the
MTU. He also said that other things could be done, such as priority or
custom queueing, or by adding a second pvc with a particular CIR, and
running voice only across that pvc.

I suppose the question remains - how does one balance the desire for
efficient transfer and movement of data across the wan, or the internet,
against the desire to get clear and recognizable voice across the wan or the
internet? My reading indicates to me, at least, that there continues to be
much discussion about this.

Chuck


books referenced:
Gil Held - Voice & Data Networking
 Elliot Lewis - Configuring Cisco Voice Over IP

Eric Waguespack <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> They, (we) don't recommend changing the mtu, we DO recommend Configure
Multilink
>
> PPP with Interleaving /FRF.12 fragmentation setup rules for Voice over IP
> connections over Frame Relay.
>
> -Eric
>
> Chuck Larrieu wrote:
>
> > One reason might be a move to voice over IP. While I am not really up to
> > speed on this yet, I recently attended Cisco sponsored AVVID training,
and
> > this was a point that was made. On the internal network, having a
smaller
> > MTU helps greatly on the voice over side. Voice packets suffer less
delay
> > when data packets are smaller rather than larger. Voice packs don't have
to
> > wait around for large data packets to go through. Less delay = better
voice
> > quality.
> >
> > I asked specifically about the issues on the data side, and the
instructor
> > did point out that ATM, with a packet size of 53 bytes, was highly
efficient
> > and did not cause data services to denigrate.
> >
> > I suppose there is the additional overhead of fragmenting and
reassembling
> > large packets. And a major issue if the DF bit is set. One more reason
never
> > to set the DF bit, I suppose.
> >
> > Chuck
> >
> > -----Original Message-----
> > From:   [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of
> > Robert John Lake
> > Sent:   Monday, June 05, 2000 9:58 AM
> > To:     Clark, Jason
> > Cc:     '[EMAIL PROTECTED]'
> > Subject:        Re: setting mtu size on a 2611
> >
> > Hi,
> >
> > Why do you want to change the MTU size.... You are going to walk into
> > serious issues if you do.
> >
> > Robert
> >
> > "Clark, Jason" wrote:
> > >
> > > Good Morning
> > >
> > > I am trying to manually set the MTU size on a 2611 and am receiving
the
> > > following message % Interface Ethernet0/0 does not support user
settable
> > > mtu."  Is it not possible to manually set the MTU size on Ethernet
> > > interfaces?
> > >
> > > TIA
> > >
> > > Jason
> > >
> > > ___________________________________
> > > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> > > FAQ, list archives, and subscription info: http://www.groupstudy.com
> > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> >
> > --
>
> --------------------------------------------------------------------------
--
> > --
> >  Robert LAKE MSc - Customer Support Engineer      |           |
> >  E-Mail: [EMAIL PROTECTED]                          |           |
> >  Phone : +32 2 704 5434                          |||         |||
> >  Fax   : +32 2 704 5804                         |||||       |||||
> >  Parc Pegasus                               ..:|||||||:...:|||||||:..
> >  De Kleetlaan, 6                            C i s c o   S y s t e m s
> >  B-1831 - Diegem - Belgium                     Euro TAC - Brussels
>
> --------------------------------------------------------------------------
--
> > --
> > Cisco Systems - Empowering the Internet Generation
>
> --------------------------------------------------------------------------
--
> > --
> >
> > ___________________________________
> > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> > FAQ, list archives, and subscription info: http://www.groupstudy.com
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> >
> > ___________________________________
> > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> > FAQ, list archives, and subscription info: http://www.groupstudy.com
> > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
> ___________________________________
> UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> FAQ, list archives, and subscription info: http://www.groupstudy.com
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
> ---


___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to