On 6/13/05, Matthew Toseland <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 10, 2005 at 07:17:03PM -0000, Anonymous wrote:
> > In message <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >
> > >> I haven't watched the lists for some weeks now (I was on a longer
> > >> business related trip). So my question: Do you still plan on switching
> > >> the whole network over to UDP based transfers?
> > >
> > >Yes, although we may implement a TCP based transport as an alternative.
> > >Nextgens seemed to be interested in that (but he had no time to do it).
> > >Would all users who would be compelled to leave the network if they
> > >can't use it over TCP please reply to this message.
> >
> >
> > I'd have a problem with it because while am able to throttle freenet's TCP
> > traffic with reasonable success, I am absolutely ignorant of how to do it
> > with UDP protocols.  Also, I'm not certain, but I believe that my router /
> > firewall and local server will combine to be a problem to passing on and
> > throttling UDP traffic.  Un-Throttled is totally UN-Good.
> 
> Do you need to? We have control over individual packets with UDP; it
> should be pretty easy to throttle. Also I don't see why it shouldn't be
> easy to do it with token bucket filters in iptables, regardless of
> protocol...

How will the node throttle itself when it detects that UDP packets are
not reaching their destination in expected time? Or will it think that
the other node is having problems and redirects traffic to other nodes
(which wouldn't help at all in this case).

> > I have to be able to vary speed from as low as 512bytes / second (when
> > bandwidth is needed temporarily for something else) to 60Kilobytes / second
> > (or higher) when there is no other demand on the local network.
> 
> Well, this is bad for the node as it doesn't know about it and can't
> respond properly to it... but do what you have to do :|.

I'm in the same situation as well. I have 5 HTB traffic classes
(interactive, normal, bulk, p2p and freenet), which get my limited
bandwidth in order (Freenet gets bandwidth only when nothing else uses
it). I have a long packet queue on Freenet's class, so no packet gets
lost.  When available bandwidth suddenly goes down, the extra "burst"
of traffic goes into the queue, causing latency. This causes TCP's
automatic throttling to kick in and slow down. The queue is gradually
flushed, which causes latency to go down and allows TCP to speed back
up.

The obvious problem with traffic shaping and Freenet is that the node
assumes that every node it was connected to suddenly becomes much
worse. This might not be a big issue when the number of connectable
nodes is smaller than the connection limit (and thus every node's
estimators suffer similarly), but it might cause the node to
unnecessarily tear down existing connections and make new ones.

-- 
  Mika Hirvonen <[EMAIL PROTECTED]>
_______________________________________________
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Reply via email to