[MUD-Dev] datagrams

[Steve Houchard]

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

> Steve Houchard wrote:
> > * If you don't put in congestion control (recovery/avoidance) you're no=
t
> > doing it right; I forward flames to the TCP-friendly homepage at:
> >=20
> >         http://www.psc.edu/networking/tcp_friendly.html
> >=20
> > Unless you've written such a system or studied these topics it will be
> > time consuming and frustrating to write these bits.
>=20
> ACK, I have read some of the stuff by now, but I am not sure if I will
> be as nice as mister Mahdavi wants me to be ;^).  I think I would go for
> something simple, as I don't expect to use much bandwidth and have to
> send messages with priority (such as personal tells). Maybe it would be
> sufficient to switch to lower resolution graphics and such when I sense
> packet loss above a certain level, then slowly increase resolution...?

Well, hopefully you're not broadcasting graphic-type information from your
server to your clients otherwise bandwidth will be a problem.  If you're
just sending updates and positions and such at a macro-resolution
interval you shouldn't have a problem.  Even halving your window (or
reducing by 1/4) on a retransmission is preferable to doing nothing.  But
then again, you're already quarterway to TCP. =20

> > (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
> Mahdavi and Floyd writes the following on a webpage ("TCP-Friendly
> Unicast Rate-Based Flow Control"):
>=20
>         The MTU may be determined using an MTU discovery
>         algorithm[RFC1191], or may be assumed to be the minimum
>         acceptable value for TCP of 576 bytes.
>=20
> I guess this means that even 512 bytes is pretty safe? That would indeed
> be convenient.

That sounds like an ipv6 number.  Also remember that if a single fragment
is dropped the packet will (eventually) be retransmitted.  TCP will often
wait until it's gathered 500 or so bytes before sending out a packet
(Nagle's algorithm). =20

> > * Sending multiple copies of packets when unneeded is probably not a go=
od
> > 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 :)
>=20
> Well, you did at least make me read rfc2018. Isn't what you describe
> rather TCP centric?  I figured that it would be a good idea to send ACKs
> multiple times to avoid unnecessary resending of data (which tends to be
> much larger than the ACKs).

Doesn't need to be TCP centric but the ideas do come from TCP research.
If you ACK every packet received and periodically send an ACK keepalive
then you shouldn't need to retransmit ACKs.  A SACK-based scheme is
generally better because it carries more information which can be used to
more selectively retransmit data.  A non-piggybacked ACK carries no data;
i.e., it's pure overhead.  It takes time for a router to chug through the
data in that header to send it on out.  It's a non-trival cost that
dominates if the packet is small. =20

SACKs let you decouple what to send from when to send it.  More
specifically, it lets you better determine which packets to retransmit and
thus behaves much better in a high-loss network.  The only thing you're
required to have with a SACK-based system is the ability to totally order
packets (i.e., have sequence numbers). =20

> > 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 r=
un
> > across in my own code though--just give the word.
>=20
> Abstract descriptions and issues are almost certainly very very useful
> and welcome! :)

For those who are interested, you can see our most recent and yet
still very rough draft of the paper at:
=09http://www-personal.engin.umich.edu/~stevehou/final6.ps

It includes a copy of our packet header (which looks striklingly similar
to TCP) and the way we do SACKs.  Ignore the evaluation parts; there's a
bug in our code that skews our timing data (we've already been reamed for=
=20
this). =20

Steve





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