[e2e] TCP in outer space

[Pablo Molinero]

Cannara wrote:

> [...]

> 
> I'd summarized some of this in a draft response to another msg., so will try
> not to repeat anything.  The fact is that network processors are now available
> that have (per chip) >500,000,000 RISC cycles available per second and >1GByte
> fast RAM available for processing packets (corresponding to about 2M
> packets/sec).  They also implement queue controls like RED in hardware.  Since
> basic RFC1812 routing takes <200 such cycles per packet, we now have designs
> emerging with well over 100 extra instructions available per packet to do
> whatever.  MPLS numbers are similarly good.  All these numbers more than
> double next year, and will reach 10Gb/s packet processing per chip about a
> year later.  If someone is interested in processor vendors, I'll be happy to
> pass names off list.


I find these numbers interesting.  Even if they are quite impressive, I 
think that that 2 Mpps is still far away
from the 31 Mpps needed to treat TCP ACKs back-to-back in an OC-192 
link. According to Moore's
law we would need 6 more years (doubling every 1.5 years) to see this 
processing power, but who knows
what link rates we might be looking at by then.

My believe is that we are heading towards a situation in the core where 
we have fast links and slow routers.
This comes from the observation that for the next 10 years link 
capacities will double every 7 months,
whereas processing power will double every 1.5 years. As time passes the 
goal of designers will start
shifting from making an efficient use of their links to reducing the 
amount of per-packet processing.

Pablo Molinero-Fernandez
molinero at stanford.edu


> 
> The point is that router/switch code can do far more these days than ever
> imagined when the decision to offload performance and capacity decisions from
> 'gateways' (routers) was made years ago.  The corollary is that this is not a
> surprising reality.  So, for example, rather than simply using the hardware
> RED capability now available to drop packets, use it to generate a more
> intelligent control statement to the sender.  Source Quench and its original
> purposes have been discussed, but consider that intelligent folks might even
> go further -- let a little of this processor-cycle wealth be directed at the
> network-layer without tricking the assumed transport, which is not the source
> of all the traffic.  This is, of course being discussed.  
> 
> As an example and just for kicks, keeping the TCP input so loved, consider a
> compatible technique that starts, say before RED drops -- let the router
> fabricate a statement to the sender via an Ack that simply reduces the
> apparent receive window.  The router code knows all that's needed to do this
> and can use an Ack seq # that won't cause any other response at the sender but
> seeing that it's time to reduce outstanding payload (segments).  If a router
> does this on all connections in queues that are approaching some RED watermark
> of choice, all dropping may be avoided for those connections, and performance
> will improve.  Even more ambitious attempts along these lines can be thought
> up, I'm sure.  This is only suggested as an example, but the point is that
> this is old news and not "rocket science" by any means.  It does mean thinking
> a bit differently and doing more than just running yet another NS simulation.
> 
> Alex
>