Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement violates TCP.)

[julian_satran@il.ibm.com]

Jim,

I think that Matt is approaching the problem correctly.
In a world of interoperable devices you can't require this type of
alignment for implementations that
are neither bound nor willing to use it. Moreover outboard machines,
proxies, caching devices can do havoc to
your initial alignment since they are neither aware and/or willing to use
them.
Your stuff can work only as an option or at least an initially negotiated
option and as such it is out-of-bounds for this WG.

Regards,
Julo

"Jim Williams" <jimw@giganet.com> on 29/11/2000 19:00:32

Please respond to "Jim Williams" <jimw@giganet.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement
      violates   TCP.)




I think Matt is approaching the problem with a different mind
set than I am.  (I am saying this for clarity, not to
argue that mine is correct.  In fact I am quite open minded.)

My approach was that framing recovery is something that
that can be accomplished by two protocol specific TCP
implementations
without violating the TCP spec or breaking backward
compatability.  It is certainly not a violation of TCP
if a particular implementation aligns iSCSI headers
with TCP segment boundaries.  It would be a violation
to REQUIRE that endpoints do that.

Matt is I believe arguing that a standard TCP implementation
should be able to mark iSCSI header alignment in a manner
that allows an iSCSI specific implementation to exploit it.
This narrows
down the potential methods considerably.  If the urgent pointer
mechanism turns out not to work, the only alternative may
be to use each N'th byte in the TCP stream as alignment point.

|                              |  <-- N'th byte points

--------------------------------------------------------
|   block  |  block      | pad | block |  block | ...
--------------------------------------------------------

If the objective is to enable two specifically enabled
TCP implementations to recover alignement, then the
technically cleanest method would be to modify TCP.
Although this group is not the place to do that, this
does not change the fact that it can be done, and is
the best technical solution.  The draft below
demonstrates that it can be done without modifying
TCP.  The arguments for doing that are more political
and procedural than technical.

(Yes ... SCTP is an alternative, but is not the subject of
this note. :)

----- Original Message -----
From: Matt Wakeley <matt_wakeley@agilent.com>
To: <ips@ece.cmu.edu>
Sent: Tuesday, November 28, 2000 2:14 PM
Subject: Re: TCP limitations (was Re: ISCSI: Urgent Flag requirement
violates TCP.)


> Jim Williams wrote:
>
> > http://www.ietf.org/internet-drafts/draft-williams-rdmatcp-00.txt
> >
> > is an example of a shim layer that provides a mechanism
> > to recover framing upon loss of TCP segments.
>
> This draft has the following text for recovering framing on packet loss:
>
> "The recommended method for doing this is to assume that the RDMA
> segment is aligned with a TCP segment, and verify the correctness of
> the header fields of the RDMA segment."
>
> Aligning the iSCSI headers to begin in a new TCP segment is exactly what
we
> want.  But that "would require changes to TCP blah blah blah" which is
what we
> can't do.
>
> "If these header fields are not correct, then the NIC should fall back to
> buffering the packet until it can be processed in order."
>
> This then requires buffering on the NIC (store and forward) or data
copies
in
> the host, which we are trying to avoid.
>
> -Matt
>