On Tuesday 03 July 2007 17:05, Brian Butterworth wrote: > You seem to be using a different network to me. I'm sorry to trouble you.
*blink* You disagree with Cisco as well then? Michael. > On 03/07/07, Michael Sparks <[EMAIL PROTECTED]> wrote: > > On Tuesday 03 July 2007 13:56, Brian Butterworth wrote: > > > > a few seconds without any meaningful damage). If you were designing a > > > > protocol from scratch for bandwidth efficiency and considering > > > > quality > > > > of > > > > > > service, it would look very different from TCP/IP. > > > > ... > > > > > What utter rubbish. > > > > It's not actually. TCP is first and foremost designed for reliable in > > order > > delivery, not timeliness or efficiency. Implementations do aim to help > > with > > the latter 2 and some systems will preferentially through away UDP rather > > than > > TCP packets when forced to make the choice, in order to avoid TCP > > retransmissions (assisting TCP's efficiency). > > > > But then your next statement isn't wrong either: > > > The whole reason the internet exists is TCP/IP. > > > > The widespread availability of TCP/IP has very little to do with > > efficiency > > of link usage. (which is viewed as "good enough" generally speaking) For > > high > > bandwidth links TCP is extremely inefficient which is why protocols like > > SCTP > > are under development (and integrated into some OSs) to use different > > models > > for ramping up bandwidth usage. > > > > The widespread availability of TCP/IP is far more about relative ease of > > implementation. Indeed this seems to be a general principle in internet > > protocols. Unless a basic, half working version of a protocol can be > > implemented over the course of a few days by a few talented individuals, > > it generally gets replaced by a simpler more effective protocol. (I'm not > > talking about a version you'd want to use for a service, just a version > > that's a starting point) > > > > Over time the replacement protocol often gets more baroque (as happened > > with > > TCP/IP), until it becomes worth replacing with something more > > appropriate. > > > > FTP giving way to HTTP is a prime example of this. There are always > > others. > > Often the approach that "wins" is the one that is simplest to implement. > > Even today, many web servers will still understand an HTTP/0.9 request. > > > > You have to also bear in mind that inadequacies of TCP for certain > > applications is why protocols like RTP, etc have been created. Sometimes > > this relates to efficiency, sometimes QoS. > > > > Assuming that TCP is the most *efficient* way of using a link isn't > > really valid. It's efficient enough and _relatively_ simple which is what > > counts. > > > > A detailed description of the issues affecting TCP/IP can be found here: > > * http://preview.tinyurl.com/fn3wz > > (redirects to a Cisco website) > > > > It's a few years old, but covers the core issues affecting TCP/IP > > efficiency. > > > > Regards, > > > > > > Michael. > > > > - > > Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, > > please visit > > http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. > > Unofficial list archive: > > http://www.mail-archive.com/[email protected]/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
