SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: IP fragmentation



    Joshua Tseng wrote:
    > 
    > I was wondering if it would make sense to require that the
    > DO NOT FRAGMENT bit to be set on IPv4 packets carrying iSCSI
    
    Hosts already SHOULD do path MTU discovery, so it is not
    the sender who's behaviour you are specifing, but the
    behaviour of the receiver.
    
    I think you are asking that the reciever of iSCSI IP
    packets with DF=0 send a ICMP error, or drop the
    packets quietly.
    
    If the receiver sends an ICMP, how do you prevent
    malicious unauthenticated people from using iSCSI
    receivers as denial of service multiplers?
    
    If the receiver doesn't send an ICMP, how do users
    discover the configuration error?
    
    It is also not clear to me how you would implement
    this proposal on a general purpose operating system
    (that is, on many iSCSI initiators) where the Path
    MTU feature is globally set for all protocols.
    
    The mere act of checking the DF bit may prove
    difficult on some platforms.  For example a
    mainframe that does TCP offload will have no
    idea what the DF bit of an individual IP packet
    is, and to find out will cost many more channel
    accesses than allowing fragment reassembly
    on the offload processor.
    
    Finally, and most significantly, I would oppose your
    suggestion simply because it is a long-held IETF design
    philosophy that receivers should be robust.
    
    The best IETF standards also avoid prescribing implementation
    optimisations, leaving these for less normative informational
    RFCs.  Until we have more experience with the protocol
    in practice, it would seem to me unwise to seek to optimise
    unbenchmarked performance.
    
    I suggest that your proposal only considers one
    of the two partners in a iSCSI session, the
    target.  Be careful in that optimising the target
    performance you don't reduce the initiator
    performance and suboptimize the system.
    
    Glen
    
    -- 
     Glen Turner                                 Network Engineer
     (08) 8303 3936      Australian Academic and Research Network
     glen.turner@aarnet.edu.au          http://www.aarnet.edu.au/
    --
     The revolution will not be televised, it will be digitised
    


Home

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