In message <1gu4k9r.1u891uk17tq3m3M%manu@netbsd.org>Emmanuel Dreyfus writes
>Jonathan Stone <jonathan@dsg.stanford.edu> wrote:
>
>> I have changed the Subject: line to accurately reflect the subject of
>> discussion, namely, Emmanuel's attempts to write a multicast application
>> which  achieves a network meltdown via multicast, in pursuit of an
>> information-dissemination applicatoin.
>
>Are you always that harsh on people that just come to fix something they
>thought to be a problem?

Mnul, what you've done here is to compound two or three of the
fundamental mistakes in networking:

Mistake #1: not liking TCP and trying to build something better for a
specific purpose.

Mistake #2: Trying to build a non-rate-adaptive application

Mistake #3: Trying to run that application over multicast(!!)

Mistake #4: Trying to sidestep (violate?) the end-to-end principle, in
this case in a misguided attempt to improve performance.

Even one of those is going to annoy anyone with the technical savvy to
help you.  Compounding all of them will *really* annoy such people
(the impact of those particular mistakes, when compounded, are
synergistic.)

But, not only did you make those mistakes, you started off by whining
that NetBSD had a bug, that it was not conformant with SUSv3.  But
there's no technical reason to *ever* claim the current behaviour is
in violation of standards.  None at all.  Yet you repeatedly made that
claim, even after the standard had been quoted to you.

Do you see how such repeated obnoxious complaints are going to cause offense?


But if that wasn't enough: your goal here just a dumb goal, it's
actively dangerous.  Just by pursuing it, you are inviting _severe_
criticism.  (Try asking for help, just for help, without bogus
offensive claims of "bugs", in a forum like e2e, and see what kind of
response you get.)

Any application which is non-rate-adpative, which is deliberately
designed to send at or above line rate, and which is completely
non-responsive to congestion, is _by definition_, a denial-of-service tool.

Any application which exhibits such behaviour not just over unicast,
but over multicast, is (by definition) a distributed denial-of-service
tool.  Using it in the wider Internet might well leave one liable to
criminal charges in various jursidictions. Or cause one's upstream ISP
to cut off service. (Or both).

No, this is not a strawman; I am completely serious.  this exactly is
*why* nobody ever, ever deployed protocols like NETBLT except in
dedicated test LANs.  Or take VOIP.  VOIP technology uses similar,
fixed-rate, largely non-rate-adaptive, non-congestion- responsive
flows. (The flows can adjust between a very few codec rate steps,
hence the "largely" non-rate-adaptive).

There has been serious discussion on the e2e list recently, over
whether such flows may be a risk to the Internet as a whole. The
answer, so far, is that the individual VOIP flows are so small -- tens
of kilobits each -- that they aren't a risk.

multicast applications at gigabits are a whole different story.


[[ ...Snip list of design goals, stated and inferred... ]]


OK, I stand corrected on #6.  I stand by the word "attempt" in #1, as
you agree to the wire-speed requirement in #2, and you haven't
achieved that. So we agree to the following list, revised at the end:


    #1.  You are Attempting to write a multicast application for
    dissemination of information.

     #2. You require the application to send at wire rate.

    #3. You deliberately wish the application to be non-rate-adaptive:
    fixed-rate, wire-speed.

    #4. You deliberately want the application to be non-congestion
    responsive (technically subsumed in earlier points, but worth listing
    in its own right).

    #5.  You want *reliable* dissemination of information: that is,
    your application is expected to recover from packet drops. Or at
    least, from some packet drops.

and a revised #6 and #7:

    #6.  As currently designed and coded, your current application
    experiences some [periodic? repeated? we haven't seen] drops which
    occur inside the sending host, due to overflowing the
    per-interface send queue.  Let's skip your bogus (and to some,
    offensive), claims about "bugs" for now.

    #7. For reasons of your own, you decline to recover from those drops
    using receiver-initiated NACKs, and you would instead prefer to detect
    and resend from the host which has (by definition) temporarily
    exceeded its send capacity.



Manu, the key point you should notice here is that your cited problem,
viz., dropping packets from the if_snd queue, *is* by definition a
case of congestion at the if_snd queue.

In effect, in deciding to ignore congestion, you made what fans of
``Yes Prime Minister'' would call a "courageous" decision.  Then you
encountered congestion, in the form of congestion between the UDP send
routine and your output interface send queue.

You decided to ignore congestion.  Now, you encountered congestion.
It's your bed, now lie in it. Don't whine that somehow, NetBSD
(or any other *BSD code; its all the same in this regard) is at fault.


By the way: if you take this list to another expert practitioner in
networking, they are going to give you a very hard time indeed about
the combination of "multicast" on the one hand, and "non-rate-adaptive"/
"non-congestion-responsive" on the other.  Most, if not all expert
practitioners will remonstrate with you over the combination of #6 and #7,
citing the end-to-end principle.