Re: iSCSI: Towards Urgent Pointer Consensus

[Michael Krause <krause@cup.hp.com>]

At 02:34 PM 11/22/00 -0800, Venkat Rangan wrote:

>In cases 3) and 4) also, we do not need Urgent Pointer, because
>the bandwidth achieved will drop to a point (in response to packet
>drops), where you do not need a large amount of anonymous buffers.
>Additionally, the receiving end in both cases is a custom TCP
>implementation. It is possible to design such implementations
>where anonymously held buffers get "transferred" to its rightful
>owner when sequence holes get filled, without any additional data
>copies. As long as the TOE memory address space is also addressable
>by higher-level (iSCSI) software layer, this copy can be avoided.
>Perhaps, your "custom implementation" assumes certain constraints
>on memory addressability between iSCSI and TCP layers.

Comments:

- TCP is not a stagnant technology and what is viewed as custom 
implementation by some today will become de facto implementation next 
year.  iSCSI should be looking forward as to where TCP can and will be 
based on its requirements and determine whether this will harm the adoption 
rate sufficiently to warrent an architectural change.  Based on past / 
current experience, the majority of OSVs will tune their implementations 
next year to support high-performance iSCSI implementations because the 
customer-visible value props are so strong that customers will demand it.

- Loss rates are primarily a function of congestion.  Fabrics can be 
provisioned to support specific bandwidths with guaranteed 
throughputs.  This is true within the data center, the LAN, the MAN, and 
the WAN.  The issue is one of cost and there are many service 
providers  generating such volumes that the volume cost models are being 
applied.  As such, I do not believe the specification should be bound by 
the numbers put forth for the Internet (another constantly updated fabric).

- VM page remapping as implied above is not practical.  A good OS will be 
using large pages to improve processor TLB management (a major performance 
win) and as such a given iSCSI request will not consume a full page (e.g. a 
PA processor can support variable pages up to 1GB virtual pages; many other 
processors support variable pages that also exceed most iSCSI requests).


Mike