Re: Determining if it is "safe" to send UDP packets

From: Spiro Trikaliotis (news-200501_at_trikaliotis.net)
Date: 01/30/05 

Date: Sun, 30 Jan 2005 12:10:34 +0100

Hello Roger,

thank you for your answer.

Roger Levy <rhl@i3e.org> wrote:

> I could be glib and say the answer is TCP but I assume you have good
> reasons for using UDP.

Yes, we have. We want to transfer images obtained from a camera as fast
as possible over a wireless link. The protocol used is tolerant of
packet losses, thus, it is not a big problem if the one or the other
packet does not get received.

Every image is packed. Unfortunately, the packed images appear almost
all at the same time. That's the reason why we have to send them out in
bursts.

As we are sending on a (direct) wireless link (but assuming we are the
only one sending anything), we do not need to take into account any
potential problem like congestion, routers that add processing delay, or
the like.

For testing purposes, we tried to connect two machines via fast
ethernet, utilizing a cross-connect cable. Thus, we are sure that it is
the sender's OS that is throwing the UDP packets away.

> I think a possible answer to determining when it is "safe" to send is
> to automate the process that you have described as a "training"
> process that takes place before sending important data. Training is
> essentially what modems do to determine the highest reliable data
> rate. Training would require you to define a message protocol that
> enables the destination machine to detect when training is is being
> executed and how to respond to it. The complexity of such a scheme
> would probably lead me back to TCP.

As real-time is a major issue, TCP or a similar approach is obviously
out of scope. Furthermore, as I told before, we do not need each and
every packets. Anyway, getting only the first 10%, and nothing
aftermore, is *not* enough for us.

It is very interesting to see the scheme of the packet losses if you
just send out a burst: The first x% of packets are all send. Then, the
next 100%-x% are not send, they are almost all completely lost. After
this, again x% are send, and so on. It really looks like a full buffer
on the sender's site.

Another problem with TCP is its assumption that a lost packet is due to
a congestion (which is not true in our case, as we do not have
congestions), but lost packets are rather frequent on the wireless link.

> Another approach is to make your UDP path more reliable but you
> haven't given enough network topology for anyone to tell you where to
> start.

Well, we have A, and we have B, connected directly via the wireless
link. It cannot be more simple, can it? ;-) BTW: We need a datarate of
not more then 150 KB/s on the wireless link - a data rate which it can
surely handle. Furthermore, our protocol is not allowed to perform any
handshaking. The receiver is fast enough (this is know before-hand).

> Recently I shifted to Linux for this problem because I felt there was
> more tunability available.

BTW: We have exactly the same problem with Linux. ;-) Only our own
drivers in RT-Linux give us full control, and there, it works.

> My belief is that you are tackling a problem that is ripe for
> optimization but you need to understand that the potential for errors
> or lost data will always exist with UDP.

Yes, we are fully aware that the potential for errors or lost data is
always there with UDP. In fact, that's exactly what we want. ;-)

Anyway, we do not want the kernel to "unnecessarily" throw away some
packets on its own. At least, we want to be informed of this process, so
we can react.

Thank you for your input,
   Spiro. 

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/

Relevant Pages

  • Re: Determining if it is "safe" to send UDP packets
    ... IMHO for "reliable" UDP you need to use some Quality of service ... Maybe your network is QoS enabled and your traffic gets classified as "below ... > the sender's OS that is throwing the UDP packets away. ... > next 100%-x% are not send, they are almost all completely lost. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: UDP packets dropping
    ... I am facing a problem which anyone who has worked on any UDP ... If packets are lost, no acknowledgements ... upper protocol depends on reliable delivery you have to implement that with ...
    (comp.os.linux.embedded)
  • Re: UDP concept help please
    ... > The way I understand it, UDP is an unreliable protocol and packets can ... > the queue and do whatever with it. ... If packets are lost it will probably be because of network conditions [line ...
    (comp.lang.c)
  • Re: UDP Packet are lost
    ... > my problem is that we are losing a lot of UDP packets. ... Don't user UDP for a critical app. ... when packets are lost. ...
    (comp.unix.solaris)
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)