Now a TCP Question

[Alex Tweedly]

wouter wrote:

>
> We/I are/am very interested how you will tackle the packet integrity,  
> packet loss, packet order  on UDP connection -  server and client-wise.
> Please spoil some bandwidth on this and keep it posted here.
>
Jim can answer for his specific case, but I'll make some general remarks 
on UDP protocol / application design.

There is (or should be) no concern about packet integrity. UDP Checksums 
cover the data portion of the packet as well as the headers, so you have 
high reliability. They are optional; on some hosts you MAY disable them, 
but really there is no reason to do so nowadays, we have adequate CPU or 
special hardware to calculate checksums.

Note there are a number of apps which will handle misordered packets 
only in the special case where two packets are reversed,  but handle any 
further misordering by dropping the errant packet and using their 
data-loss scheme to cover that (rare) case.

Out of order packets and packet loss can generally be handled together 
(and should be, since an OOP will initially resemble packet loss). 
Generally, the applications for which UDP is suitable fall into one of 
the following categories (with corresponding approach to the packet 
order problem):

- servers handling many small queries from large number of servers 
(e.g.DNS, DHCP)
      Packet loss is handled by retries - if a client has not received a 
response within some time period - it tries again. If number of retries 
gets too high, it gives up. The response to a query contains info to 
associate it with the original query - either explicitly, such as a 
cookie / seq number, or implicitly, e.g. the request was for DNS info 
for a specific domain, the response contains that info.
    Out of order packets is pretty much not an issue - requests are 
largely independent, frequently single packet anyway.

 - streaming  media (e.g. VoIP, streamed audio/video, video conf)
    The application layer is highly dependent on timely delivery, but 
resistant to problems due to packet loss (e.g. codecs which spread an 
audio sample over 2-4 packets, such that loss of any one is not 
important. They have (typically) very short playback buffers, so cannot 
tolerate delay well - e.g. they couldn't afford to re-query for a 
missing packet anyway. OOP is usually not an issue because the packet 
contains a timestamp which allows it to be slotted into the playback 
buffer in the correct order, regardless of delivery order (or discarded 
if the playback point has passed).

 - streaming data (stock info feeds, commodity trading, betting info, etc.)
   Usually have real-time requirements (or very large audiences) which 
preclude use of TCP (which they'd really rather have done had it been 
possible :-)
   Use sequence numbers to detect missing data (often with a playback 
buffer scheme to handle simple misorderings).
   Often the application is fairly insensitive to lost data (e.g. trade 
info can be ignored briefly, and will be fixed when a summary comes in 
later (assuming not too many packets get lost) - so it's common to 
monitor packet loss, and do nothing more provided the loss remains low 
enough (<1% say).
  There's a sub-category for "rolling" data, e.g. teletext, where the 
data is refreshed periodically, enough that loss can be simply ignored.

 - online games (particularly "twitch" games with real-time needs)
      Often use a periodic "summary" message to synchronize data, 
allowing the app to temporarily ignore lost packets; discovery of a data 
synch problem causes triggered updates of the relevant part of the data. 
Other than that, much the same as VoIP case.

 - polling  many clients providing periodic updates to central point
      Clients sending keep-alives, where one (or two) can be lost 
without the central point deciding a client has gone - so insensitive to 
loss or misordering. This remains true even it the "poll" provides more 
info, so long as the info is only being summarized, or can be requested 
specifically if crucial decisions are to be made (routing protocols, 
such as RIP or EIGRP)


Never ignore the possibility of designing in robustness at the 
application data layer. This can be anything from the mind-blowingly 
simple - (e.g Real Audio back in the very early days, when their UDP 
service simply sent every packet twice), to mind-numbingly complex (e.g. 
Digital Fountain - uses Forward Error Correction coding to produces a 
data stream which can suffer arbitrary packet loss without any data 
loss, tuning the acceptable overhead against the observed packet loss 
rates).

If you find you are getting too deeply into recovery issues from packet 
loss (i.e. a request for retransmit, time outs, etc.) then you should 
probably just punt and go with TCP. If that's not an option, then make 
sure that any retransmission scheme is sensitive to congestion - i.e. 
you can't simply request additional data transmissions over and above 
the base transmission without throttling the base transmission, or you 
will fall into congestive collapse much too easily.


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.2/349 - Release Date: 26/05/2006