Subject: RE: iSCSI: IP fragmentation

From: Dennis Young <[email-masked]>
Date: Thu, 7 Jun 2001 19:39:15 -0700

Josh,
I think this is a good idea.
Does this mean we should do a MTU discovery on the path between the 
iSCSI initiator and target so that we can do intelligent DataPDULength 
selection.
Maybe the default is to keep the DataPDULength at 2 units (1 unit = 512
bytes)
to avoid fragmentation, assuming the interface at the two ends are Ethernet.
-dennis

-----Original Message-----
From: Joshua Tseng [mailto:[email-masked]]
Sent: Thursday, June 07, 2001 6:10 PM
To: [email-masked]
Subject: iSCSI: IP fragmentation

		Folks,

		IP fragmentation is an issue which will affect the
performance, logic and
		HBA/NIC memory requirements of iSCSI implementations. Note
that
		fragmentation by intermediary switches and routers is not
permitted
		in IPv6 (hence, the DO NOT FRAGMENT bit does not exist in
IPv6).
		With this in mind, and in the interest of optimizing iSCSI
performance,
		I was wondering if it would make sense to require that the
		DO NOT FRAGMENT bit to be set on IPv4 packets carrying iSCSI
and
		that iSCSI implementations not perform IP fragmentation for
IPv6.
		This will allow for performance optimization if
implementations do not
		have to check for fragmentation and handle reassembly.

		Any thoughts?

		Josh

---

From: Glen Shok <[email-masked]>
Date: Fri, 8 Jun 2001 06:28:08 -0700

So 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:[email-masked]]
Sent: Thursday, June 07, 2001 11:00 PM
To: Joshua Tseng
Cc: [email-masked]
Subject: Re: iSCSI: IP fragmentation

> 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
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 8 Jun 2001 11:08:53 -0400

Mandating special behavior between the IP stack and the TCP stack is outside
the scope of the IPS charter.  However, a TCP stack that implements PMTU
discovery already sets the DF bit in IP packets.  It seems reasonable to
state recommendations regarding the RFCs implemented by the TCP stack that
iSCSI is running on top of, like "the TCP stack SHOULD support RFC 1191,
<etc>"  Implementors should also be aware of RFC 1435 and RFC 2923.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]