DCC server high latency

Vernon Schryver vjs@calcite.rhyolite.com
Fri Jan 25 14:39:44 UTC 2008


> From: Mark v Herpen <markvh@office.cambrium.nl>

> The thing is that I wanted to test the DCC server, before I wanted to 
> connect it the the global network of DCC servers. Because the latency 
> was so high, I wanted to fix this first, before contacting you for a 
> server ID or the contact other persons the exchange checksums.
>
> I didn't see the 'artificially delaying of the DCC server when its 
> disconnected to other peers' in the documentation. So I was thinking 
> that I did something wrong. Perhaps it's is a good thing to include this 
> in the DCC docs. :)
>
> I will contact you personal for a server-id and other info.

The documentation for the DCC code is already too long, and there are
many aspects of the DCC code that are not documented except in the
source.  I think operational documentation should be limited to telling
people how to run the code.  Internal features should be documented
elsewhere.  The artificial delay that happens when flooding is not
working is invisible except that it makes things work better.  Besides,
in a sense the artificial delay is documented in the license.

Assigning server-IDs and setting up peering takes some effort from me
and other people.  I have to find prospective peers that are both close
and far.  I look for topologically distant peers so that the worst case
path length in the network is minimized.  That reduces delays on flooded
reports of new streams of bulk mail and so increases DCC effectiveness.
I also look for at least one peer that is geographically nearby (say
within 1000 km) for some "fate sharing" against Internet problems.
Operators of the prospective peers often need to adjust firewalls to
pass TCP connections to and from port 6277.  At some organizations
firewall changes require documentation, official approval, and time.
And then there is provisioning the ~1GByte/day incoming and ~1GByte/day
outgoing bandwidth for each flooding peer.  That is a lot of work only
for testing.

As with your request about 6 weeks ago to subscribe to the DCC-Servers
mailing list to "explore the possibilities" of DCC, despite the
restriction on subscriptions to operators of DCC servers, is there
some other way you could do your tests that does not require special
consideration?

If you want to test the effectiveness of DCC filtering, why not
run some mail through dccifd or dccm using the public DCC servers?

If you want to measure the latency of dccd, why not run two DCC
servers flooding each other?  That would violate the license, but
that evidently has not been a consideration.

Please note that if your mail system would not filter more than 100,000
mail messages per day with DCC, it would best to use the public DCC
filters instead of a local server.  The load imposed on the rest of the
DCC network is generally mimimized by having smaller sites use the
public servers.   


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.