RE: An alternative to TCP (part 1)
Richard Carlson wrote: You're right, the TCP peak was 1.48Gbps from the show floor in Dallas to a storage cluster at Berkeley Laboratory. Single applications using multiple stream. Bottleneck link was 1.5Gbps provisioned circuit on Qwest link from convention center to DARPA's HSCC pop node. This beat last years (SC'99) 1.2 Gbps rate Microsoft achieved running TTCP on a single PC with 2 Gbit Ethernet cards (Redmond to Portland). Rich Peak rate alone is a meaningless measure of performance. The TCP session may have reached peak for a small fraction of the session duration and the rest of the time, the link may have been severely under-utilized. A meaningful performance measure here is average or percentile link utilization over the tcp session duration. I believe the inital question was answered, though. Peak rate alone tells me that it is _possible_ in the "near" future to exhaust the sequence number limitation of TCP. Even still, is it wise to allow for such conditions? Or would it be wiser to influence the community use larger frames over these large, fat links? ___ Send a cool gift with your E-Card http://www.bluemountain.com/giftcenter/
RE: An alternative to TCP (part 1)
1. There are two annoying incompetence of TCP. One is that TCP does not distinguish packet loss caused by network transmission error from that caused by network congestion. The congestion control and avoidance mechanism makes TCP drop its transmit window upon detecting a packet loss, thus lowers the transmit rate even if the loss is caused by physical link transmit error. This results in an unnecessary reduction in link bandwidth utilization, especially in the environment of wireless physical links. Agreed. This discontinuity allows room for NAT-like "fixes" that don't benefit the entire well being of the Internet as an entity. This has been seen with some of the limitations of PEPs (split connections more specifically). I have explored such options for wireless systems. The trade matrix looks a lot like one for a NATed network -- good in the short term, questionable in the long term. The other is that the unit of TCP sequence number is byte (octet) while the the sequence number is only 32 bit wide. It is not a big problem for a no-more-than-100Mbps network. But in a modern gigabit network, it takes only about 36 seconds to consume the whole sequence number space when transmitting at the maximum bit rate. Is this really a problem? How often would a single TCP session have allocated to itself an entire gigabit link? I'm not aware of any end systems or apps that generate data at this rate (especially for any extended length of time), much less accept it. Maybe I'm looking at this wrong. Respectfully, -Larry This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above.
RE: An alternative to TCP (part 1)
Jun'an Gao wrote: it is probably better to do traffic shaping at the service provider network edge, for some reason of accouting, congestion control, or required by service-level-agreement Or possibly at the carrier or access network edge. Carrier networks are not necessarily owned by the service providers, which introduces another level of resource consideration. regards, -Larry This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above.
RE: solution to NAT and multihoming
Mr. Wood, Philosophically, I agree with your points in the previous email. Reality dictates another perspective. A good philosophy does not necessarily translate to realizable solutions. If this was a discussion on whether or not NAT should be used in the IPv4 Internet, your points would be well taken. As we all know, this is far from the actuality. Your arguments are somewhat like discussing how many smoke detectors to put in a building that is currently burning down. Respectfully, -Larry -Original Message- From: Lloyd Wood [mailto:[EMAIL PROTECTED]] Sent: Friday, January 26, 2001 2:26 PM To: Kevin Farley Cc: [EMAIL PROTECTED] Subject: Re: solution to NAT and multihoming On Fri, 26 Jan 2001, Kevin Farley wrote: - no, not everyone wants to run every conceivable application/protocol to their client machines, they are happy with the subset they chose. you have an interesting spin on 'choice'. How can you choose something before you've tried it? Before it's been written? - no, not everyone wants to participate in the great global address space of the Internet, they just want to access Internet-connected devices. That is tantamount to saying 'We don't need clean air! We don't even want to know what clean air is! We just need to be able to breathe!'. I'm tempted to equate the walled-garden restrictions imposed by NAT with the walled-garden restrictions imposed for copy-protection: http://cryptome.org/jg-wwwcp.htm either way, consumers are disadvantaged. Given the argument that NAT restricts the available applications and/or protocols, a potential buyer of the device must then choose the one that meets his or her requirements. or the requirements of his users. Note the disconnect of needs and interests there. L. [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ This message is intended only for the individual or entity to whom it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited, and you are requested to please notify us immediately by telephone at (321-956-8846) and return the original message to the address above.
