Re: QoS - Calculating path latency

I'm glad it sort of makes sense to you now.
Yes, if your network is layer 2 (i.e. it forward frames and not bits)
then it could get messy if your access rate is not the same at both ends.

BTW, the guy using trains that I shamelessly took the idea from is
best known by the E=mc^2 formula :) He is the one using the (for me at
least) awkward noum "embankment" in a nice work called "Relativity: The
special and General Theory".

Good luck with your studies,
-Carlos

Dave Serra @ 13/01/2013 14:23 -0300 dixit:
> So after sleeping on this one I drew a chart that proved out what you
> were saying in that since there is overlap between serialization dealy,
> propdelay and deserialization delay. No matter how I plugged the
> numbers into the model it kept showing me the sum of the 3 was always
> negated by exactly the deserialization delay. I kept
> the deserialization delay the same as the serialization delay in my
> model though. I suspect that if I made deserialization delay faster
> then serialization delay (as is the case with frame-relay hub and spoke)
> I will get different results. But for now it makes sense.
> I then read your e-mail and it too makes sense though I've never been
> quite good with associating trains and packets ;) I appreciate the
> time you took on this one as I'm sure lots of people are simply bystanding.
> :)
> Make a small loan, Make a big difference - Kiva.org
> *From:* Carlos G Mendioroz <tron_at_huapi.ba.ar>
> *To:* Paul Negron <negron.paul_at_gmail.com>
> *Cc:* Dave Serra <maybeedave_at_yahoo.com>; "ccielab_at_groupstudy.com"
> <ccielab_at_groupstudy.com>
> *Sent:* Sunday, January 13, 2013 6:04 AM
> *Subject:* Re: QoS - Calculating path latency
>
> Thanks :)
> Dave, I don't know why but trains are a good analogy for understanding
> time and space, so let's go there:
>
> You have station A (or embankment :) with a train, and it takes some
> time to "serialize" it into the rails that go to station B. Here, we
> call "rails" the rails that start just at the end of the station, what
> we could call the station port.
>
> Then you have the time it takes the train to cover the rail tracks to
> station B. I'm reluctant to call that propagation delay, but that would
> be it. And then, train should enter station B.
>
> Now, consider a 0 length rail: stations back to back. Train departure
> and arrival happen at once! Ok.
>
> Now consider a one car long rail. If you take the time it takes for
> departure, you only need to add a one car length travel for the train to
> be completelly arrived.
>
> Now take a long track. The issue is that "as the train is getting out of
> the station, it also begins travelling. This time you would have to
> deduct from the travel time, and then add the arrival time, which are
> the same. D + (T - D) + A, so to say. But A = D, so total time gets down
> to D + T.
>
> If I did not confuse you too much, I should have convinced you :)
>
> BTW, time shift is a shift, i.e., of events happening at different times
> but being otherwise the same. If the events happen at the same point in
> time, there is no shift :)
>
> -Carlos
>
> Paul Negron @ 13/01/2013 02:06 -0300 dixit:
> > Carlos has a tendency to do this. :-)
> > In a good way!
> >
> > Paul
> >
> > Paul Negron
> > CCIE# 14856
> > negron.paul_at_gmail.com <mailto:negron.paul_at_gmail.com>
> <mailto:negron.paul_at_gmail.com <mailto:negron.paul_at_gmail.com>>
> >
> >
> >
> > On Jan 12, 2013, at 9:08 PM, Dave Serra <maybeedave_at_yahoo.com
> <mailto:maybeedave_at_yahoo.com>
> > <mailto:maybeedave_at_yahoo.com <mailto:maybeedave_at_yahoo.com>>> wrote:
> >
> >> 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 <http://kiva.org/>
> >>
> >>
> >> ________________________________
> >> From:
> >> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>
> >> To: Dave Serra <maybeedave_at_yahoo.com <mailto:maybeedave_at_yahoo.com>
> <mailto:maybeedave_at_yahoo.com <mailto:maybeedave_at_yahoo.com>>>
> >> Cc: "ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>
> <mailto:ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>>"
> >> <ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>
> <mailto:ccielab_at_groupstudy.com <mailto: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 <http://kiva.org/>
> >>> *From:*
> >> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>>
> >>> *To:* Dave Serra
> >> <maybeedave_at_yahoo.com <mailto:maybeedave_at_yahoo.com>
> <mailto:maybeedave_at_yahoo.com <mailto:maybeedave_at_yahoo.com>>>
> >>> *Cc:* "ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>
> <mailto:ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>>"
> >> <ccielab_at_groupstudy.com <mailto:ccielab_at_groupstudy.com>
> <mailto:ccielab_at_groupstudy.com <mailto: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 <http://kiva.org/>
> >>>>
> >>>>
> >>>>
> >> Blogs and organic groups at http://www.ccie.net/
> >>>>
> >>>>
> >> _______________________________________________________________________
> >>>>
> >> Subscription information may be found at:
> >>>>
> >> http://www.groupstudy.com/list/CCIELab.html
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> --
> >>> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>> LW7
> >>> EQI Argentina
> >>>
> >>>
> >>
> >> --
> >> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
> LW7 EQI
> >> Argentina
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net/
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net/
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>> LW7
> EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net/
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net