Re: QoS - Calculating path latency

With my previous example of the 56k link between California and NY I was
trying to create an example where propagation delay is actually longer then
serialization delay and show that serialization is complete before the packet
reaches the other side due to a very large propagation delay. I probably
botched that given how long packets take to serialize on a 56k link. So let
me change my example to a 10Gig link between Californial and NY. Now in this
case the packet will fully be serialized before it reaches the other side and
it is in this case I believe we would have to take into
acount 'deserialization' delay (I really like that one ;) ). So in that
example we really can't overlap time persay.
 
The 'time shift' concept is an
interesting one when at that same point in time bits are being serialised at
one end and deserialized at the other but it does not take into account of
everything. For example, take a 1500byte packet (12000 bits) that has
serialized the first 2000 bits at the sender before the first bit reaches the
receiver. Now the 1st bit at the receiver should be deserialized at the same
time as the 2001st bit is serialized at the sender. So we now only have to
account for the deserialization delay of the last 2000 bits as the packet at
the sender has finished serializing them so there is no more overlapping time.
 
This is a pretty good discusion as I only came up with the above after think
about what you said. You are making me think ;)
 
 
 
 

Make a small loan,
Make a big difference - Kiva.org
 

________________________________
 From:
Carlos G Mendioroz <tron_at_huapi.ba.ar>
To: Dave Serra <maybeedave_at_yahoo.com>
Cc: "ccielab_at_groupstudy.com" <ccielab_at_groupstudy.com>
Sent: Saturday, January
12, 2013 7:08 PM
Subject: Re: QoS - Calculating path latency
  
Well, it does
not matter if the cable is 1 mt or 30km, because
that time is taken into
consideration by propagation delay.

But tx serialization takes exactly the
same time that rx
"deserialization" takes, and once you do the "time shift",
they can overlap.

If you are able to see that the distance is not an issue,
then you
should see that one bit out the tx buffer happens at the same
"shifted"
time that the same bit enters the rx buffer.

Your sentence about
not being able to start receiving until you end
transmitting is not true. It
depends on which time is greater:
serialization or propagation...

-Carlos
Dave Serra @ 12/01/2013 17:06 -0300 dixit:
> hmmmm....I suppose on 10Gig links
of short distances in a store and
> forward switch this might happen and it
most certainly does happen on a
> LAN where R2 is a cut-through switch as R2
can be bringing a packet in
> while R1 is still serializing the tail end of it
but lets assume that
> these are long (from california to NY) links of 56k.
In this scenario
> R2 can not bring the packet into the router (what I am
calling
> 'serialization delay'. maybe I should call it 'input-serialization
>
delay' for better clarity) until R1 has finished serializing the packet
> and
it reaches R2.
> Make a small loan, Make a big difference - Kiva.org
> *From:*
Carlos G Mendioroz <tron_at_huapi.ba.ar>
> *To:* Dave Serra
<maybeedave_at_yahoo.com>
> *Cc:* "ccielab_at_groupstudy.com"
<ccielab_at_groupstudy.com>
> *Sent:* Saturday, January 12, 2013 2:58 PM
>
*Subject:* Re: QoS - Calculating path latency
>
> Hey Dave,
> it might be that
the R2 read serialization happens exactly as (during)
> R1 write serialization
? Then, they do not add up, but only one of them
> is used to account them
both.
>
> -Carlos
>
>
> Dave Serra @ 12/01/2013 16:41 -0300 dixit:
> > I have
a question. I've been reading Wendell Odom's cisco press book
> 'Cisco
> >
QoS, Exam Certification Guide'. In it he calculates total latency
> for the
> > path as processing delay, serialization delay, propagation delay,
>
etc... My
> > question is why do we calculate serialization delay only as
the packet is
> > leaving the interface and being placed on the wire and not
ALSO when the
> > packet is being received by the remote router. Surly there
is some
> delay to
> > take an incoming packet off of the wire and store the
bytes in memory
> prior to
> > processing it. So in other words, in the
network as
> PC1-->R1-->R2-->PC2 why
> > are we not including the delay to
get the packet off of the wire and into
> > R2. ie, assume packet is already
in R1--> processing delay, seralization
> > delay of R1, propagation delay to
reach R2 and then serialization
> delay again
> > to get the packet into R2
for its processing?
> >
> > BTW, I know I grossly
> > missquoted Odom by
only including processing delay, serialization delay,
> > propagation delay,
etc... He has a lot more delay types in his book. My
> > question really
only focuses on the packet that is in R1 and getting
> into R2
> > so I
omitted the others.
> >
> > I appreciate anyone's feedback.
> >
> > Thanks
guys.
> > Make a small loan, Make a big difference - Kiva.org
> >
> >
> >
Blogs and organic groups at http://www.ccie.net/
> >
> >
Received on Sat Jan 12 2013 - 20:08:19 ART