Re: Reordering (was Re: TCP limitations ...)

[Glen Turner <glen.turner@aarnet.edu.au>]

vern@aciri.org wrote:
> 
>         J.C.R. Bennett, C. Partridge, and N. Shectman,
>         Packet Reordering is Not Pathological Network Behavior,
>         IEEE/ACM Transactions on Networking, Vol. 7, Number 6,
>         December 1999, pgs 789--799.

Hi Vern,

Yes, I had read that with interest when it was published in ToN
and have also read your disseration.

I'm not worried about reordering for enterprise deployment of iSCSI,
as in that environment you have the ability to specify the equipment
used, and thus can avoid configurations that are prone to reordering.

It is the enterprise storage use of iSCSI that 'requires' some means
of reading the next iSCSI PDU should the previous one be delayed.
And thus it is this application that is driving the use of URG as
a iSCSI PDU delimiter.  (Although my own belief, totally unsupported
by implementation experience, is that these reordering and loss events
can be engineered within an enterprise storage network to be so rare
as not to be of concern).

For Internet deployment on a best-effort path (which is where
my interest lies), delays are to be expected in any case so the
queuing of iSCSI PDUs due to packet reordering is of much less
concern.

Pathological reordering (eg: every second packet) would be
a problem.  I've asked that ISPs be given the hint about
this in the draft (ie: by making the desirable traffic 
engineering attributes be low congestion and low reordering).

In our network, we would then establish a MPLS label switched
path for iSCSI that does not load share across our parallel
undersea links and does end-to-end rather than by-section
protection.  Other ISPs could do engineering suitable for
their network.

> The authors found frequent reordering on packets sent through
> MAE-East.

And they argued that this behaviour was to be expected and
was unavoidable, rather than due to misconfiguration.  They
then made a case for improvements in TCP, arguing that it needs
to behave better in the face of now-expected reordering.

Such improvements would help iSCSI over TCP as much as
any other protocol.

Because SCSI can handle some re-ordering of PDUs and because
there are multiple iSCSI sessions over the one transport connection,
there's also an argument for running iSCSI over some non-stream
reliable transport for enterprise applications.  It concerns me
that the textual organisation of the current draft makes this addition
difficult, even if such a protocol has yet to be determined.

However, I'm simply a network engineer and Linux hacker, whereas
other people on the list work for the cream of the storage
companies.  I'm writing an iSCSI implementation for Linux as
a project that will hopefully lead to the grant of a masters
degree.

Regards,
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