Subject: Re: fixing send(2) semantics (kern/29750)
To: Emmanuel Dreyfus <manu@netbsd.org>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-kern
Date: 03/27/2005 02:14:56
In message <1gu2vhj.1812tpa1jtlz28M%manu@netbsd.org>,
Emmanuel Dreyfus writes:

>Jason Thorpe <thorpej@shagadelic.org> wrote:
>
>> What app is this?  Why doesn't it use TCP, which would not have this
>> problem?
>
>That's pkgsrc/mbone/mdd, a home-grown multicast data distribution tool.
>It's not perfect yet, but I'm still trying to improve performances.
>Multicast means no TCP, I have to do with UDP.  

Boggle.  And so now you're telling _me_ about multicasting and UDP?
Wow. Thanks, Emmannuel, I haven't laughed out loud that much much in...
years, I think.  No offense, but based on what we've discussed here,
it sounds like you've gotten in way over your depth.

If you really want reliable multicast distribution, you really should
be aware of the prior art: SRM, with what we called the "crying baby"
problem? Log-based receiver reliable multicast?  TCP-SMO? 

You could do much, much than look for citations on TCP-MSO by Liang
and Cheriton; basically TCP over single-sender multicast, with an
"expected" rate and a way to eject receivers who persistently can't
keep up.  Tho' I only ever heard of a Linux implementation.  Manuel
suggested "mtcp", which I hadn't heard of; from Citeseer, I think
means M/TCP, by Vasaka Visoottiviseth, formerly at Nara, now at a
university in Thailand. The online paper at Nara mentions work on a
FreeBSD-4.1 implementation.

It sounds like what you're attempting is an application that is
completely unresponsive to congestion and which has no rate limiting:
it eats all the bandwidth that eats all the bandwidth it can get. If
so, it should be pulled from pkgsrc *immediately*, as a danger to you
and to others. (It's a DDOS tool, pure and simple.) Or at least mark
it, clearly and distinctly , as for deployment only in over-provisioned
private LANs or over-provisioned private internets (with a lowercase i).
Unless, that is, it's already so labelled.

There's a darn good reason no-one *ever* deployed NETBLT, except as a
research toy on dedicated LANs. Trying the same basic approach, only
over multicast, would be even worse.  (You *do* know what NETBLT is,
right? And why nobody deployed it except as an extremely limited
research tool? And why people are likely to jump on you from a Great
Height if anyone deploys your tool?)