SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Towards Urgent Pointer Consensus



    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
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:18 2001
6315 messages in chronological order