I'm coming in on the middle, so this point may have already been made:
You should do the fragmentation and interleaving at the datalink layer with
FRF.12 or multilink PPP. Don't set the MTU on the interface for the
following reasons:
It will cause IP to fragment. The packets will remain fragmented until they
reach the end-node recipient. This causes extra work for the recipient. In
addition, it's silly to have fragments on the other end if the other end is
a Gigabit Ethernet, for example. With FRF.12 and multilink PPP, the partner
router reassembles at the datalink layer.
Some protocols, such as AppleTalk and IPX, don't have a fragmentation and
reassembly function. Setting the MTU to a small size simply breaks those
protocols.
Priscilla
At 11:22 PM 6/19/00, Chuck Larrieu wrote:
>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]
________________________
Priscilla Oppenheimer
http://www.priscilla.com
___________________________________
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]
