SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI Autosense Consensus, Connection next steps



    
    In practice a number of interesting applications (like a machine room or
    limited LAN) can control (or easily know) their configurations, and so might
    be able to use a feature that was configuration dependent (SCSI, Fibre
    Channel, and Ethernet all have some configuration constraints today for
    certain things).  I agree that this is not the case for the general network
    environment (lots of mixing of low layer protocols, fabrics not under the
    control of a single organization).
    
    Jim
    
    
    -----Original Message-----
    From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
    Sent: Wednesday, September 06, 2000 4:24 PM
    To: ips@ece.cmu.edu
    Subject: Re: iSCSI Autosense Consensus, Connection next steps 
    
    
    > About 1 year ago we had this "transport bundling" aka load sharing IN
    > SCTP. At the request of the IESG it was removed because (if I remember
    > right) it causes all sorts of problems with Congestion Control and
    > is still deemed a research topic by the IETF (belonging to the
    > IRTF).
    
    Interesting.  This speaks volumes.
    
    I think more than anything else this goes to the heart of the `it
    won't work' claim.  I have claimed that connection bundling support
    should either:
      a) be in the transport (or a low network layer), because layers
         above the transport (ULPs) do not have effective control over
         network path.
    or 
      b) be in the highest possible layer, because the low level
         components can not be engineered to provide the desired behavior
         without compromise, so ultimately the user must be exposed to, 
         aware of, and control the nature of the compromises.
    
    > It is aong the same lines (to a small degree) as to why you don't
    > want multiple TCP connections.
    
    Very roughly.  The specific problem is that NONE of the layers in an
    IP end-point have complete control over path selection.  The IP layer
    has the best control over this, and it only controls the initial
    interface selection.  There's no robust way to know that outside of
    the first (and possibly last) hop, you're actually using separate
    paths.  If there is a shared path component, bundled connections
    through different interfaces will mess with congestion control in the
    same way as two connections between the same end-points.
    
    This doesn't mean that it's impossible to control path selection in
    ALL cases.  It's just that you have to carefully control the network
    configuration in addition to the software behavior.
    
    This is an issue even in the fault tolerance application.  You can not
    say ``all you need to do to get fully redundant paths is hook two NIC
    cards to each endpoint.''  If the intervening network is beyond your
    control, you have no idea, and no way to tell what multipathing you're
    actually getting.
    
    The question is whether there should be a feature in iSCSI which
    breaks if and when lower layer path selection logic changes.  I am
    arguing that a clean separation of concerns between iSCSI and the
    lower layers on path selection will make iSCSI a more durable
    protocol.
    
    > But the actual implemenation of the load balancing is above the
    > transport layer... :0
    
    This has to be because IETF doesn't have an acceptable solution, so
    they're punting.  They say that connection bundling messes with
    congestion control, and then the proceed to hand the responsibility
    over to layers that are completely ignorant of congestion.
    
    Pushing this function up above the transport is not likely to
    meaningfully change the nature of the traffic flow at all.  It will
    ensure that there are numerically fewer ULPs actually using it, but
    that's about it.  A ULP solution still has the same potential failure
    modes as that same ULP using a transport level solution.
    
    Nonetheless, it certainly has been argued here that iSCSI is a ULP
    that needs this function.  If people really think that the reality
    that the feature may or may not work on a configuration by
    configuration basis is OK, and an iSCSI-specific solution offers
    something important anything over the wedge driver solution, hey, rock
    on.
    
    Steph
    


Home

Last updated: Tue Sep 04 01:07:31 2001
6315 messages in chronological order