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]/
