Don Cohen writes: >Bob Gustafson writes: > > But, But, - this is really just software. We are not trying to cram wine > > bottles down the internet pipe (although many would really like to do > > that!). > >The limitations I point out are inherent in tcp/ip. Yes, there are limitations in tcp/ip.. > > > >From the requestee point of view, I know how much bandwidth I need to > > listen to the BBC newscast, or to a company conference call. I can also > > request email and ftp sessions to work in the 'background' at a lower > > bandwidth allocation (cost?), but if I am talking to someone interactively, > > it would be nice if my packets were transferred at a regular rate without > > jitter or delay. IP doesn't do this, and one can argue that it cannot. But, > > the whole thing is run by software and software can change. > >All of the things above can already be done on a single link. With IP, to get decent QoS, you need a bit of excess bandwidth on the connection. With contention for the pipe at any point in the path from sender to receiver, the connection reverts to a 'best efforts' un-policed connection. Hmm, maybe I'm wandering into the Pub wearing a weird hat. After all, this is the Lartc mail list. >What cannot be done is make two links work like one with the >sum of the bandwidth. I can see your point. I didn't say that it was going to be easy. == I just 'measured' my DSL bandwidth at 632 kbits/sec and my Cable bandwidth at 897 kbits/sec (using bandwidthplace.com) == BobG
