On Fri, Aug 10, 2007 at 09:37:16AM +0100, Rob Oats wrote:

||  The TTN has raised several issues that really reflect the true nature of the
||  Internet as it is now and will be in the future;
||
||  1. Language and communication;
||  We forget that the Internet is international. The greatest number of users 
has
||  traditionally been located in the USA. It has been relatively easy to
||  communicate with users because they speak English. This is not the case 
here.

Interestingly, there is only one pool server in Turkey.

Also, Turkey is in the Asia zone.  I was under the impression that ttnet
were using the eu pool.  Not that these two should correspond, but it's
a differencce.

||  2. Fragility of current network infrastructure;
||  When we see situations like this we should quickly realise that the current
||  network infrastructure cannot be sustained within the current technology. We
||  don't have sufficient cheap bandwidth and the technology that we are
||  currently using has probably been stretched to the max. Our router 
technology
||  needs to be enhanced.

This is just another demonstration that it's not a good idea to put
intelligence into the network.  The network should be a dumb bitshoving
medium.  Put the intelligence into the hosts.

I've been rotated in several times and I have observed the
onslaught of ttnet on my time server.  The load at such times
is around 100 queries per second according to ntpdc -n -c monlist
<http://www.zweije.nl.eu.org/ntp/>, with around 60-80 of them from ttnet.
Despite only having 500kbit upstream, I observed no problems.  And I
shouldn't, because it's only 10% of the bandwidth.

Now, my ADSL setup is special in the sense that I have no router - the
modem is an internal one. There is no address translation, no state to
keep, and no translation tables to overflow.

I imagine that a regular external modem in bridge mode would not have
any problems with ttnet either.  Time servers behind an external modem
in routing mode will be affected by spikes such as from ttnet.  This has
been mentioned before: the problem is not the bandwidth, but the number
of connections overflowing address translation state tables.

How about having time server operators indicate that they are in this
situation, so that they can be kept out of pools with potentially high
loads (spikey behaviour)?

||  4. We really lack the ability to deal with such situations with current
||  network protocols.
||  This is an area that has been weak for a number of years. The system has 
been
||  built around the concept that all users are good and will respect the rights
||  of others. There is a need to develop systems that would "jail" rogue
||  networks. This same method is being used criminally to extort money from big
||  business.

This is just more of expecting the network to have the intelligence to
keep the bad people away from you.

I say, make the hosts robust, and keep the network dumb.  Then again,
I have no idea how to do that in this situation.  Maybe awareness among
time server operators will help.

Ciao.                                                            Vincent.
-- 
Vincent Zweije <[EMAIL PROTECTED]>    | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/>      | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |            -- Paul Tomblin on a.s.r.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers

Reply via email to