From: Gregory Gombas (ggombas@gmail.com)
Date: Fri Oct 19 2007 - 14:10:43 ART
Hi Andrew,
I'm not sure ping test is adequate since the router waits for a reply
before sending the next packet...I think you need a UDP application to
send packets at a fixed rate with specified packet size to really test
it....
On 10/19/07, Usankin, Andrew <Andrew.Usankin@twtelecom.com> wrote:
>
> Very good question indeed. I used to thing that packet will go through
> but now I'm going to dig dipper to make double sure it is.
> For now, here is what I got from labbing:
>
> R1#sh run int s1/0
> Building configuration...
>
> Current configuration : 129 bytes
> !
> interface Serial1/0
> ip address 172.16.1.1 255.255.255.0
> serial restart-delay 0
> traffic-shape rate 32000 3200 3200 1000
> end
>
> R1#sh traffic-shape s1/0
>
> Interface Se1/0
> Access Target Byte Sustain Excess Interval Increment
> Adapt
> VC List Rate Limit bits/int bits/int (ms) (bytes)
> Active
> - 32000 800 3200 3200 100 400 -
> R1#ping 172.16.1.2 size 1500
>
> Type escape sequence to abort.
> Sending 5, 1500-byte ICMP Echos to 172.16.1.2, timeout is 2 seconds:
> !!!!!
> Success rate is 100 percent (5/5), round-trip min/avg/max = 12/282/412
> ms
> R1#
>
>
> As you can see, bytes limit per interval is 800 and I'm sending packets
> of 1500+24 bites size. They all make it through.
> Andrew
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Gregory Gombas
> Sent: Thursday, October 18, 2007 7:27 PM
> To: Eric Phillips
> Cc: ccielab@groupstudy.com
> Subject: Re: Effect of shaping with small Bc, no fragmentation, and a
> large packet?
>
> I didn't mean it literally, I just meant that since the packet will
> always be exceeding bc it can never be sent...and thus dropped.
>
> Only way to know for sure is to lab it up!
>
> On 10/18/07, Eric Phillips <ephillips@squick.cc> wrote:
> > Thanks everyone for the replies, I definitely appreciate it!
> >
> > I did skip a 0 there, sorry... I was aiming for a 10ms Tc to make
> > VOIP traffic delayed as little as possible. So yes, the Bc would be
> 640 bits.
> >
> > Herbert, my numbers were referring to Shaping, so I was keeping
> > everything in bits. With policing you deal in bytes.
> >
> > I am very intrigued to see that we have three answers, so perhaps I am
>
> > not the only one that is a bit confused by this. If it is queued
> > forever, does it block the pipe while it is queued?
> >
> > -Eric
> >
> >
> >
> > On 10/18/07, Gregory Gombas <ggombas@gmail.com> wrote:
> > >
> > > Even with shaping configured, if the router queues the packet then
> > > it would be queued indefinately considering it will always be larger
>
> > > than bc and never be able to send it...
> > >
> > > On 10/18/07, Herbert Maosa <asawilunda@googlemail.com> wrote:
> > > > Eric,
> > > >
> > > > I assume you are maintaining bytes as the unit for Bc and ms as
> > > > the unit
> > > for
> > > > TC ? In that case Bc of 64 Bytes and Tc of 10ms is giving me CIR =
> > > 512Kbps,
> > > > using the formula CIR = Bc/Tc.
> > > >
> > > > In any case, what will happen to a packet that is larger than the
> > > maximum
> > > > rate permitted will depend on whether you are shaping or policing.
>
> > > > If
> > > you
> > > > are shaping, then the packet will simply be queued in the shaping
> > > > queue
> > > from
> > > > which it will then be sent at CIR. If you are policing then it
> > > > will
> > > depend
> > > > on the configured action for non-conforming traffic.
> > > >
> > > > Herbert.
> > > >
> > > >
> > > > On 10/18/07, Eric Phillips <ephillips@squick.cc> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I have searched through the GroupStudy archives, read through
> > > > > Odem's
> > > DQOS
> > > > > book, and checked out the DOC CD, but have not found a clear
> > > > > answer to
> > > a
> > > > > question that has been on my mind.
> > > > >
> > > > > If I enable shaping with a very small Bc, for example, a Tc of
> > > > > 10, and
> > > a
> > > > > Bc
> > > > > of 64, that should shape to 64kbit/sec, right? Now if I do not
> > > > > enable link fragmentation, and a large packet, perhaps 1400
> > > > > bytes comes through,
> > > what
> > > > > will happen? It can not be sent in a single Tc, and it can not
> > > > > be fragmented because link fragmentation is disabled. Also
> > > > > assume that I have no Be, or a Be too small to allow 1400 bytes
> > > > > to accumulate between Bc
> > > and
> > > > > Be.
> > > > >
> > > > > This seems like an awfully simple question, but I have not found
>
> > > > > a
> > > clear
> > > > > answer anywhere.
> > > > >
> > > > > Thank you very much,
> > > > >
> > > > > Eric
> > > > >
> > > > >
> > > ____________________________________________________________________
> > > ___
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Kindest regards,
> > > > hm
> > > >
> > > > __________________________________________________________________
> > > > _____ 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
>
> The content contained in this electronic message is not intended to
> constitute formation of a contract binding TWTC. TWTC will be
> contractually bound only upon execution, by an authorized officer, of
> a contract including agreed terms and conditions or by express
> application of its tariffs.
>
> This message is intended only for the use of the individual or entity
> to which it is addressed. If the reader of this message is not the
> intended recipient, or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this
> message is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> the sender of this E-Mail or by telephone.
This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:17 ART