|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 >
Home Last updated: Tue Sep 04 01:06:15 2001 6315 messages in chronological order |