handover latency (use UDP or TCP)

Discussion in 'Wireless Internet' started by Greenhorn, Apr 13, 2005.

  1. Greenhorn

    Greenhorn Guest

    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, Apr 13, 2005
    1. Advertisements

  2. Greenhorn

    Jure Sah Guest

    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."
    Jure Sah, Apr 13, 2005
    1. Advertisements

  3. Greenhorn

    Tom Anderson Guest

    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
    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 Anderson, Apr 13, 2005
  4. Greenhorn

    Rick Jones Guest

    [Might be good to pick a follouw-to group...my vote would be for

    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

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

    rick jones
    Rick Jones, Apr 13, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.