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 toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021121/6e1d86a1/attachment.pgp>
