re: Is TCP Past It?Hi Tony, Could RSVP be implemented in HW?
The problem with RSVP is that you really need to authenticate the request and check a policy database before you authorize the flow and configure a queue for the flow. I don't know of any ATM switches that do Q.2931 in hardware and RSVP on a generalized network is a harder problem.
re: Is TCP Past It?And, yes, there definitely is a problem with host processing. You can busy out CPU at a gigabit, easy, with modest sized packets (and don't tell me to use jumbo packets--that doesn't solve anything and doesn't match normal traffic patterns). ----------------- While the CPU appears to be "busy", whats actually "busy" in nearly every case is the memory system rather than TCP. There are some exceptionally bad versions of TCP where its not the case, but in the better versions, the actual processing of instructions not related to copying memory isn't a very significant part of the overhead anymore.
In terms of PCI-X, you have to be really careful with the quoted numbers. There are overheads and efficency issues that can cut the theoretical peak way down. You also have to have a path from the IO system to memory that matches what PCI-X can do. I dont know the answers on newer systems, but based on previous versions of PCI (going back to the first) its never usually as good as it seems on paper. And the high quoted numbers usually only work for large-block disk operations.
Yes, you could implement RSVP (or just about any other protocol) in hardware. However, that's just the theoretical answer. You also have to ask, would it make sense?
Unfortunately, the answer has to be no. It makes sense to put things in hardware when a) they are well understood and unlikely to be changing [RSVP is still evolving and will change as we stress it.], b) when performance is a serious issue [RSVP performance, after refresh reduction, has not yet been shown to be a problem], and c) when the complexity of the hardware implementation is rational [RSVP is not overly hard, but the ratio of die size to actual utilization would be poor.]
That said, I can't think of a reason to put RSVP in hardware today.
re: Is TCP Past It? I concur with skeptic, there's a lot more to high speed TCP than just the bus bandwidth. Take a look at the performance of the previous bus generation: PCI. That should have given us a nominal 600-800 Mbps in bandwidth, but after all is said and done, one would be pretty lucky to get 100Mbps of TCP through it.
Here's some of the things that would go into a "better" PC I/O architecture:
- NIC access into memory that did not conflict with CPU memory accesses. One could do this either by dual porting or just making a memory with massive bandwidth. Both are, of course, more expensive than your Fry's PC will allow. - "Smart" NIC's that can hold a descriptor ring full of packet buffers, can DMA packets into main memory, and will only interrupt the processor if the buffers on the ring fall below a low water mark. - TCP checksum verification as part of the DMA engine. - Page flipping support to avoid copies to user space. - Gather/scatter support for multipart buffers.
I'm sure other folks have a whole list of other things that they'd love to see.
re: Is TCP Past It?The problem with TCP that we're discussing here is that the congestion handling in current TCP prevents it from running fast enough to take advantage of the next plateau in host bandwidth (10 Gbps), if not the current one (1 Gbps) with real-life round trip times. This has nothing to do with whether the host implementation of TCP could be faster.
re: Is TCP Past It?Delivery of TCP/IP over a mobile channel has exactly the same problem, but at much lower bandwidths, since these systems have a lot of in-channel processing in the PHY and MAC layers and also packets have a bad habit of disappearing when the radio channel is shadowed. This results in lots of frames in the pipe plus high dropping rates (due to errors) that are mistakenly identified as congestion in the TCP layer.
Net effect is very bad throughput and/or mobile people adding all sort of horrible in-line tricks to get improve matters (like TCP-proxies in the network just before the radio link).
Any solution of high speed TCP must also address these mobile issues.
Remember that even if mobile bandwidths are lower it is likely that there will be a lot of mobile hosts soon and the last thing we need to "mobile-TCP" and "high speed TCP" flows trying to share the same edge and core routers with completely different congestion control extensions compared to "plain vanilla TCP".
re: Is TCP Past It?Perhaps the net has to be thought more of as a unidirectional medium, like a CD-ROM. During session creation, the ends communicate the bandwidths of the local connection to the net (like the fact that a home PC is on a DSL line) as well as the FIFO size in the computer- the transmitters then have to obey these parameters when they send so as to not overload the receviers. I think it's worthwhile to do this in any case, since the operating system might be able to estimate the load on the local links.
This would work for error-free non-congested networks. To handle the occasional congestion (drop-outs) or bit errors, use forward error correction and interleaved transmission like on CD-ROMs. If the latency is very large, you might as well retransmit the entire file if there are any errors.
re: Is TCP Past It?This reply is certainly not against Walter or Bobby. I am always reminded of the ex JDSU boss who once said 'It's the consumer stupid'. I have seen the IT industry go from Boom to Bust. The best assessment of the IT industry is from non-tech folk's like me who have invested heavily in IT stocks and have lost all. The recovery will happen only when the average consumer desires a product that is different from what is available today at a reasonably lower cost. Let us start from what is available today. 1. POTS 2. Dial-Up 3. Fraudband 4. Cell-Phone Item # 3 is fraudband available to me and you through cable and DSL which fortunately, is always on but at a cost of $35 to $50 per month.
As and when true broadband is available to the average consumer (either through fiber or through some other means) at a reasonable cost, this industry will languish like the steam driven rail engine.
True broadband will displace all items from 1 to 4. POTS=History Dial-Up = POTS = History Fraudband = Cable/DSL = History Cell-Phone = History because wireless VOIP over true broadband will be the next killer app. 10 gigs/40 gigs/chromatic dispersion/http/fttp/is fine with the tech folks but ultimately it is the consumer that will decide the fate of the IT industry. JMHO LM
"10 gigs/40 gigs/chromatic dispersion/http/fttp/is fine with the tech folks but ultimately it is the consumer that will decide the fate of the IT industry."
Of course you-¦re right. But the winning techonology is what matters to us, as we are working in the industry that provides that type of service to the customer. So it IS VERY relevant to discuss technologies.
That-¦s pretty obvious i guess in every business. Figuring out what your costumer wants and how can you provide it cost effectively for both.
Could RSVP be implemented in HW?
The problem with RSVP is that you really need to authenticate the request and check a policy database before you authorize the flow and configure a queue for the flow. I don't know of any ATM switches that do Q.2931 in hardware and RSVP on a generalized network is a harder problem.