Re: [LARTC] Re: RFC - bandwidth optimization idea

[Ed W <lists@wildgooses.com>]

>Wait, you're trying to send more data than the link can take? Then
>send UDP, throttle it at the local end with a drop-oldest qdisc. Then
>you get the effect of 'most recent data is best'. Anything more
>compilcated in terms of priority either needs a custom qdisc, or your
>application needs to not try and send more than the link can take.
>  
>

The situation described is real and complex.  For example I run an email 
service which caters for people using satellite phones (1,200 baud on a 
good day), but the whole point is that they don't need to change any 
settings when they jump on a 10Mbit leased line connection...

This is a total pain to optimise.  Ideally I would like an API to be 
able to limit the congestion window on the local machine for a 
particular connection (which I don't think exists on either windows or 
linux?).  This way the OS will report that the queue is full quickly to 
the local program without buffering up a ton of data.

The issue in my case is that you have two simultaneous streams in 
transit for email, one to receive new mail and one to send mail out.  In 
the case of the sat phone it's possible to have net buffers which are 20 
secs or so long and so when you send out a status message to say "email 
received successfully, send me the next one", it can end up queued 
behind a bunch of lower priority data for a VERY long time.  Often these 
buffers are on the remote ISP end where you have very little control.  
This is a serious slowdown on a link which is costing you $1.50/min.

My main focus has been adjusting the protocol to be less interactive, 
but it would be nice to have more operating system support for these 
fringe cases

Ed W
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc