[MUD-Dev] datagrams

[Steve Houchard]

On Thu, 27 Apr 2000, Ola Fosheim [iso-8859-1] Gr=F8stad wrote:

> The technicalities of Internet is not one of my strong points.  I'm
> trying to figure out what the best strategy for an UDP based protocol
> is, but I don't really have the pragmatic data which would make the
> process easier.

Good lord, something I can contribute to!  My area of research is network
protocols, specifically congestion control and flow control.  I've written
two such systems in the last year (RMS:  Reliable Message Service, and
STMPI:  Stream-based Transport-layer Modular Protocol Interface).  Both
have featured congestion avoidance and recovery and both have implemented
a SACK-based system of acknowledgement and retransmission.  Below are some
cursory answers and other related points. =20

* If you don't put in congestion control (recovery/avoidance) you're not
doing it right; I forward flames to the TCP-friendly homepage at:

=09http://www.psc.edu/networking/tcp_friendly.html

Unless you've written such a system or studied these topics it will be
time consuming and frustrating to write these bits. =20

> 1. What is the smallest datagram size that makes sense in combating
> packet loss?  Is 256 bytes too big in windy weather? It would be a
> relief if I could avoid splitting atomic messages like utterances (say,
> emote etc) over many datagrams and still have good performance. What is
> the best heuristic for switching to smaller/larger datagrams?

* The minimum transmission unit of the Internet is 54 bytes last
time I checked.  That's not counting UDP and IP headers (20 and 12 bytes
respectively I think; don't have references atm to verify).  I
unfortunately don't have any recent data on this but I do know that it's
an active area of research.  IPv6 has an MTU discovery protocol built in
(at least, last time I checked).  Every time you frag a packet it's
chances of reaching the destination become exponentially lower.  You'll
probably be safe with packet sizes of 128 or 256 bytes. =20

> 2. Is serial numbering of messages and "acknowledge" messages from the
> recipient the best basic structure? (I probably should read a book on
> TCP/IP implementation gore, but I don't want to :). Or are there
> advantages with having the recipient request "lost serial numbers"?  How
> do I combat lost "acknowledge" messages? Should I send them multiple
> times in bad weather?

* Your choices for reliability are ACK (acknowledgement:  I got this
packet), NAK (negative acknowledgement:  I didn't get this packet), and
SACK (selective acknowledgement:  I got these specific packets).  SACK
works best for high-loss networks.  We tested TCP-Reno in OpenBSD 2.6 (4.4
BSD) and found that it broke down at a drop rate of 13%.  Our SACK-based
system was still usable at drop rates of 50%.  There are probably other
methods available but these are the ones I know and love. =20

* Sequence numbers can be packet oriented or byte oriented like TCP.  Byte
oriented is good if you're dealing with stream data again like TCP.  My
suggestion is message-based if you can get away with it; stream-based is a
hassle. =20

* Sending multiple copies of packets when unneeded is probably not a good
use of bandwidth.  Reasong being that "bad weather" usually means
"congested router" and blasting more packets through that router isn't
likely to help (typically it makes things even worse).  IMHO a fast
recovery with exponential backoff SACK system is the best way to go
although I tend to be a little biased towards SACKs :)

> 3. Do you use TCP or UDP between your own servers on your local network?
> Is the overhead with TCP large enough to warrant using UDP locally?

* In my own designs I typically use TCP.  My AI nodes are designed
to connect to the main server via TCP on a special server port.  I don't
ever expect traffic to be a big deal even at a 100ms decision cycle for
any number of agents I'd want to run (I'd run out of processing power
first). =20

* Things on a local network typically aren't bad (depending on the traffic
of course).  I think that the link layer (ethernet) is responsible for
retransmitting packets lost based on collision although it would make more
sense to just punt and let higher levels deal.  (again off the top of my
head; the link layer is not where I tread) =20

* TCP was meant to run on machines far lower power than the ones we use
today (even the crummy ones I use).  Unless you're feeding a gigabit
backplane or even filling most of your 100Mbit connection you won't even
notice the computational drain.  You probably end up paying more in
interrupts than in computation (hence soft timers). =20

> 4. If somebody feel inclined to share the main structure used in their
> datagram based protocols, then please do so! :)

Unfortunately, my code is now property of the Regents of the University of
Michigan so I'm not able to pass that along (not that the code is
particularly good anyway).  I can post packet formats and issues I've run
across in my own code though--just give the word.

Steve






_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev