|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: IP fragmentationSo taking a look at this from a network perspective, it depends where you want iSCSI to potentially be implemented. Doing MTU discovery in a private (leased line) network is not unrealistic as you have control over your routers, and you already know (for example) that you don't have MTU between any 2 points set below 1500. Yet if you would like iSCSI to be able to run over the public Internet or over a leased IP Service Provider Network, then you are unaware of what the "cloud" looks like. Most Service Providers, and the Internet will not send you back an ICMP (for security reasons) telling you why they dropped the packet, thus the frames will never make their way from the sender to receiver, and it will be almost impossible to debug why. I agree with Glen, you have got me make the receivers in an IP environment as robust as possible. You can't count on the network that you are sending your data over to be the perfect network. Glen Shok SAN Valley Systems -----Original Message----- From: Glen Turner [mailto:glen.turner@aarnet.edu.au] Sent: Thursday, June 07, 2001 11:00 PM To: Joshua Tseng Cc: ips@ece.cmu.edu Subject: 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 |