handover latency (use UDP or TCP)

Hi,
I am currently testing a product which uses mobile ip and switches
between wired and WLAN connections as needed based on connectivity. I
would like to measure the latency in handover. I am considering the
use of UDP stream (from the moible computer to another computer on the
home network) and see the tcpdump and use the difference between the
timings of last packet sent on first interface and first packet sent on
the currently used interface as criteria for measuring the latency in
switchover. Should i use TCP instead, i am thinking of using UDP as it
doesn't have any flow control.
Can you please comment on all aspects.


greenhorn.

Greenhorn wrote:
> I am currently testing a product which uses mobile ip and switches
> between wired and WLAN connections as needed based on connectivity. I
> would like to measure the latency in handover. I am considering the
> use of UDP stream (from the moible computer to another computer on the
> home network) and see the tcpdump and use the difference between the
> timings of last packet sent on first interface and first packet sent on
> the currently used interface as criteria for measuring the latency in
> switchover. Should i use TCP instead, i am thinking of using UDP as it
> doesn't have any flow control.
> Can you please comment on all aspects.

I don't think I exactly understand the switchover part, but about the
protocols in these aspects (not just the theory):
* TCP when used to send a single packet will need somewhere around 3 to
4 times as much time to accomplish, but since it talks to the servers
that route it it is more reliable.
* UDP while low on overhead for small quantities of data, has the nasty
habbit of not getting trough sometimes. Now while the theory is that
"some UDP packets sent may not arrive", it needs to be said that in
reality (up to my experience) this means if you send one UDP packet and
it doesn't arrive, you may have sent 500 and not one of them will arrive
even tho the network relaying it may be working just fine.

Your problem with using UDP would be that you'd have no way to diagnose
what the problem is, it may be anything down to something as stupid as
too low priority on highly loaded QoS-supporting networks somewhere on
the internet or it may in fact be a disconnected network cable on your PC.

I'd suggest you use TCP, but do read up to your options as to how to use
it, the information you are trying to gather just might be reliably
obtainable from as much as attemtping a TCP connection and then letting
it die without sending any data trough.

Good luck!

--
Model: INFJ
Primary function: Coprocessor
Secondary function: Cluster commander

"Even a child who is pure at heart
And does his homework neatly
May become a wolf when the wolfsbane blooms
And the moon is full, completely."

On Wed, 13 Apr 2005, Jure Sah wrote:

> Greenhorn wrote:
>
> > I am currently testing a product which uses mobile ip and switches
> > between wired and WLAN connections as needed based on connectivity. I
> > would like to measure the latency in handover. I am considering the
> > use of UDP stream (from the moible computer to another computer on the
> > home network) and see the tcpdump and use the difference between the
> > timings of last packet sent on first interface and first packet sent
> > on the currently used interface as criteria for measuring the latency
> > in switchover.

Sounds about right. Bear in mind that some packets might just get lost,
though; slap a serial number in each one so you can match up sends and
recieves to catch that.

I guess you really want to measure two things: how long it takes from
handover starting to get back to normal operation, and how long packets
are delayed during handover (ie before you get back to normal). The former
will govern user experience in applications like web browsing (where they
might notice the network freezing if it's for more than a few hundred
milliseconds, but won't notice a few extra tens of ms on individual
packets), the latter in applications like streaming media (where those
tens of ms can become perceptible). Interesting bit of work!

> > Should i use TCP instead, i am thinking of using UDP as it doesn't
> > have any flow control. Can you please comment on all aspects.
>
> I don't think I exactly understand the switchover part, but about the
> protocols in these aspects (not just the theory):
>
> * TCP when used to send a single packet will need somewhere around 3 to
> 4 times as much time to accomplish, but since it talks to the servers
> that route it it is more reliable.

What do you mean by "it talks to the servers that route it"? If by
'servers that route it', you mean the routers between the two peers, then,
AIUI, that's not correct - as far as the routers are concerned, an IP
packet is an IP packet, whether it's got a TCP segment or a UDP datagram
inside it. If you mean the host that's on the other end of the connection,
then you're absolutely right, but that's an odd use of the term 'route'.

> * UDP while low on overhead for small quantities of data, has the nasty
> habbit of not getting trough sometimes. Now while the theory is that
> "some UDP packets sent may not arrive", it needs to be said that in
> reality (up to my experience) this means if you send one UDP packet and
> it doesn't arrive, you may have sent 500 and not one of them will arrive
> even tho the network relaying it may be working just fine.

True, but as long as you detect and think about that, it's okay, in this
context.

> Your problem with using UDP would be that you'd have no way to diagnose
> what the problem is, it may be anything down to something as stupid as
> too low priority on highly loaded QoS-supporting networks somewhere on
> the internet or it may in fact be a disconnected network cable on your
> PC.

I don't think TCP gives you any more power to diagnose problems en route
than UDP; a dropped packet is a dropped packet. TCP just gives you an easy
way to detect and recover from dropped packets - whilst this is rather
useful if you actually want to shift data, if all you want to do is study
the way the network handles packets, it's completely irrelevant.

Moreover, this isn't about the internet - the traffic will, if i
understand correctly, be between a mobile station and a host on a LAN a
couple of hops away.

> I'd suggest you use TCP, but do read up to your options as to how to use
> it, the information you are trying to gather just might be reliably
> obtainable from as much as attemtping a TCP connection and then letting
> it die without sending any data trough.

I'd go with UDP, but to be honest, as long as you're capturing packets at
both ends, either will do - they'll both generate a stream of packets
through the routes, which is all you need to do the time measurements.

Do make sure the clocks on the machines at either end are in sync, though!

tom

--
No hay banda

[Might be good to pick a follouw-to group...my vote would be for
comp.protocols.tcp-ip]

Netperf has a "histogram" mode of compilation (--enable-histogram) in
the most recent bits. You could use netperf TCP_RR or UDP_RR tests
with that - although if the handover means an IP datagram might be
lost, a UDP_RR test stops cold on packet loss.

The histogram is displayed when verbosity (-v) is set to 2.

You could run one set with things going over the wireless, then one
set over the wired, and then one set with a handover in the middle and
compare the histograms.

I've not quite got the code ready to ship-out, but the next drop of
netperf code will have a "demo mode" in it where it can be configured
(--enable-demo) to emit interim results at at least a specified
interval.

Neither quite as detailed as a tcpdump trace, but it might be an
interesting starting point.

rick jones
--
Process shall set you free from the need for rational thought.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...