RE: Framing Discussion

[Michael Krause <krause@cup.hp.com>]

At 10:55 AM 12/20/2000 -0800, Douglas Otis wrote:
>JP,
>
>The VM page flipping will require blocks to be greater than or equal to
>pages in size and that these blocks are aligned at page boundaries.  Neither
>of these assumptions are true. The goal is clear, the NIC will examine the

It is more accurate to state that blocks are not always aligned since 
clearly one can make them aligned in a given implementation and quite often 
they are.

>content and then direct data payload to the system through the NIC
>interface.  The desire is to keep the buffers on the NIC small and thus
>allow out of sequence processing of the TCP stream.  This must be seen as a
>modification to the normal TCP implementation.  Such operation should
>include a complete description of the API to allow consideration of NIC
>design, inter-operability and security requirements.

Need to separate out completion and ACK generation semantics from how and 
the order that data is DMA'ed into the target buffers.  If the buffer is 
known as the target for a given operation, then the buffer can be written 
to in any order that is desired - this true for all I/O implementations 
today.  If valid out-of-order packets (critical to ensure data integrity on 
a per header / packet / segment basis since data cannot be DMA'ed until one 
is sure it is valid) arrive and it can be determined that the payload of 
these packets belongs to a known target buffer, the data can be DMA'ed into 
that buffer at the proper offset.  There is nothing in TCP to preclude such 
a design and in fact this type of operation is implemented by some vendors 
today as part of their per connection copy avoidance solutions.

Now, when valid-out-order packets arrive TCP should initiate its error 
recovery algorithms as appropriate.  Implementations are also required to 
insure that the buffer completion event is not initiated until all packets 
have arrived.  From the application perspective it is completely opaque as 
to the order the buffer is filled in and is only focused on the completion 
event to know when it may examine the buffer's contents.

I see nothing here that requires any API modifications to TCP-based 
applications nor any issue with interoperability or security since all of 
this activity is performed within the local receiving endnode.  I see no 
problem with a host-based implementation communicating with a TOE-based 
implementation since there are no wire protocol modifications w.r.t. TCP - 
the iSCSI headers are within TCP's data payload byte stream and are 
therefore independent of the TCP implementation itself.  What am I missing 
since you have brought up these issues on multiple occasions?

Mike