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.

Reply to
Greenhorn
Loading thread data ...
[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

Reply to
Rick Jones

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!

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'.

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

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 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

Reply to
Tom Anderson

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!

Reply to
Jure Sah

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.