[MUD-Dev] Re: Error tolerant UDP data streams

J C Lawrence claw at under.engr.sgi.com
Tue Dec 8 13:52:02 CET 1998


On Tue, 8 Dec 1998 07:20:04 -0500 
James Wilson<jwilson at rochester.rr.com> wrote:

> On Mon, 07 Dec 1998, J C Lawrence wrote:

> [snip]

>> ObThought: This would be particularly cute if the client ran its
>> own statistics on the incoming multiple-copy data streams and
>> sent occassional advisory packets back to the server, requesting
>> the server to increase or decrease the number of duplicate
>> packets sent according to the averaged (weighted mean) percentage
>> that are making it thru in good order.  Bad connection/lag ==
>> more duplicates and more network congestion.  Good connectivity
>> == minimal duplication.

> hrmmm... seems like I just read an RFC which said something like
> "The only thing saving the internet from congestion collapse is
> the voluntary inclusion of TCP backoff in almost every TCP
> implementation". When everybody's using this technique, doesn't
> congestion increase approx. exponentially? I.e. it's congested so
> everyone doubles the number of packets they send out, it gets more
> congested so they double again, etc...

Good point.  There would need to be some extra logic added in
attempt to detect various types of packet loss (increasing traffic
levels is not going to handle a "No route to host", or a latency
heading for multiple seconds.  Conversely, connections running over
barbed wire net or sat links, which by their nature have high rates
of drop out, would benefit.

And no, the growth curve doesn't have to be expontential.  It would
be trivial to provide brakes and limits (if you're only getting 10%
of frames you'd do better to bail than to persist).

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...




More information about the mud-dev-archive mailing list