[GNUnet-developers] Re: [p2p-hackers] Help needed: Autonomous NAT traversal test [Was: enabling bridges on NATed clients]

[Michael Blizek]

Hi!

On 11:18 Sun 07 Mar     , Stephen Williams wrote:
> I've been lurking for a while.  Apologies that I've missed most of the 
> conversation.
> 
> Michael Blizek wrote:

...

> > - Do throttling the proper way and *not* by "usleep", but by setting
> >   TCP_CONGESTION or smaller tcp window sizes if possible. "usleep" should 
> > only
> >   be the last resort. When using usleep or smaller tcp window sizes, the lib
> >   should be able to figure the proper parameters out by itself e.g. by 
> > pinging
> >   a fixed IP and looking at the response times when the net is under load.
> >   
> 
> Rate-based end-to-end flow control with bandwidth estimation, usually 
> needed at both the communications and application level, is the way to 
> solve most related problems.  I can detail and provide references.  It 
> turns out not to be very hard to implement in most cases.  Recently, we 
> called this "pro-active flow control" to try to distinguish it from 
> simple window-based flow control.

There is a thing called "congestion avoidance" which should take care of the
flow control. In linux, you can select the algorithm per-socket - and you can
sometimes set a "low priority" one. The bad thing is that this congestion
avoidance is triggered by packet loss. On slow lines with big buffers, this
might be too late. Using the latency for flow control also has its down sides,
like convergence issues.

Anyway the point is that "usleep" is one of the worst mays of doing the
throttling on the sending side (it is ok on the receiving side). The reason
is that the TCP/IP stack will create lots of small packets (increases CPU
usage of routern) which have the push flag set (which triggers ACK sending
without delay, which causes even more small packets).

> > - Provide a way for the application to tell the library which connections 
> > are
> >   important and which connections need throughput or low latency.
> >   
> 
> Yes, need a standard way to provide and propagate these hints.  Also, 
> need to provide visibility of preferences of routers (i.e. intermediate 
> systems) along the pipeline if possible.  This allows things like 
> bandwidth throttling to be visible, enforced, and accounted for (perhaps 
> by opening additional channels).

IP has a way to do this. It is called TOS field, but it is rarely used. There
is little point on TP networks anyway. If there is not enough backbane
bandwith, everybody will try to get as much as possible and nobody will set
the TOS field. They will rather randomise ports and do encryption and traffic
normalisation to prevend being slowed down. I think this parameter is mostly
interesting before the traffic leaves into the internet. 

        -Michi
-- 
programing a layer 3+4 network protocol for mesh networks
see http://michaelblizek.twilightparadox.com