On Thu, Nov 21, 2002 at 09:26:10AM -0500, Doug Bostrom wrote: > Greetings, > > I'm reposting an earlier reply to Matthew about an issue that I'm still puzzling > over. I think Matthew may not have noticed my reply, and I think his original > reply to my original post about dealing with asymmetric connections replicates a > mistaken conclusion that I also made. If I'm off-track on all of this I apologize > for wasting time, but I think there's a complication regarding the nature of ADSL > that may lead to disappointing network performance. > > <snip edited for brevity & better clarity> > > As I understand it, some requests arriving at my node are forwarded to other > nodes, with the results being passed back through my node toward the original > requester. If my inbound connecton is 2X, and my outbound connection is 1X, this > means that data going _across_ my node can arrive at my node at twice the rate it > can leave my node. If the results of data requests that cross my site can arrive > at my site much faster than they can then leave on their way to their ultimate > destination, it seems that I must _base_my_inbound_bandwidth_settings_strictly_on > my_outbound_speed. Bullshit. I have a node with asymmetrical limits. So does almost everyone else. It's not a problem. The data will get buffered, if it's small, and throttled, if it's large. That's in the rare case that a single connection comes _anywhere close_ to the upload bandwidth. > > Put another way, the trouble with relaying and ADSL is that since packets > requesting data are presumably smaller than the resulting data packets coming > back, it seems easily possible that a node will happily accept and forward many > more request packets than it's truly capable of dealing with. If the results of > request packets are larger than the request packets themselves, constipation will > always result if the inbound bandwidth settings are not arranged strictly on > outbound connection speed. It's not just ADSL. EVERYONE, except for a few people who don't mind spending as much on bandwidth as on their car(s), has an asymmetrical connection. And it really isn't a big problem. Freenet will buffer, or it will throttle. In most cases it will buffer, since we are keeping the file anyway if it's more than 1/200th the datastore size (i.e. a meg on the default storeSize). It reads it in from the source node to the datastore at some rate, and it writes it out to the requestor node at a different rate. It was always going to cache the file, so there is no big deal. But even when we get into circular buffers, and even when we overflow the circular buffers (which is rare unless you have a ridiculously small store), it will end up throttling the incoming connection just by refusing to ACK any more packets when the buffer is full. > > Even more simply expressed, it seems to this ignorant user that if a node is > capable of requesting data for relay far faster than it can actually pass it back > through the network, chaos will surely be the result. Nope. It will not. > > Based on the assumption that the total bulk of request packets is smaller than > total data packet bulk, it seems that ADSL users may in fact have to set incoming > bandwidth _smaller_ than outgoing bandwidth, counterintuitive though this may > seem. Eh? > > If all of this is true, maybe it would be a good idea to emphasize to ADSL node > operators that they have to account for this in bandwidth settings. Further, is > it possible to estimate based on data packet vs. request packet size some rough > idea of what incoming vs outgoing bandwidth settings should be? Look, if we thought this was a problem, we would not have provided separate upload and download limits, would we? > > -- > "Americans generally do the right thing, after first exhausting all the available > alternatives." > - Winston Churchill
-- Matthew Toseland [EMAIL PROTECTED] [EMAIL PROTECTED] Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/
msg02205/pgp00000.pgp
Description: PGP signature
