More notes from Haifa

[Costa Sapuntzakis <csapuntz@cisco.com>]

This is a rewrite of some previous notes that were sent out. I believe
they corresponded to Tuesday, June 20th, discussion.

-Costa

There was a review of the requirements document. Randy has
incorporated the feedback into the version 0.2 draft of
the requirements.

----------

Action Item: Add pointer to IPv6 URL naming to iSCSI spec

----------

What does it take to make a iSCSI host WAN-happy?

- need large buffers to support retransmissions, fill pipelines
        - smaller buffer degrade performance but not correctness

- support NATs and not challenge firewalls

----------------------

There was some discussion about frame synchronization
in the iSCSI protocol. Randy Haagens thought the 
mechanism of the length fields scheme was somewhat
fragile on long-lived connections. 

There were two issues: detecting loss of synchronization
and finding synchronization.

Luciano Dalle Ore pointed out that a CRC or well known
magic number in the packet could be used to confirm
synchronization (or loss of it).

As for resynchronizing, three proposals were discussed:

   - having each iSCSI PDU be a fixed length 
           (never lose syncrhonization, in theory)
   - using special byte sequence to denote packet bounadry
       (with byte stuffing of course)
   - augment TCP to have message boundaries

------------

Large discussion on iSCSI framing and CRCs

Main issues on CRCs and reliability
   - Do nothing
   - TCP-layer CRC (CRC on datagram)
   - iSCSI layer CRC

Higher layer CRCs were seen as being able to detect the most
kinds of errors. Unfortanately, any CRC higher than the TCP segment
may require doing another pass after data has been put into memory,
costing main memory bandwidth and performance.

The iSCSI layer CRC was proposed in a couple different forms:
covering iSCSI messages, every n kilobytes in the iSCSI stream,
or covering only iSCSI data. 

Luciano Dalle Ore pointed out that IPSec provides a very strong 
CRC with its authentication header  (MD5 checksum). A well-known 
key (say 0) could be used to avoid the need to do key exchange for 
authentication.

Consensus: IPSec for extra integrity

------

An optimization to iSCSI was discussed. The suggestion
was that each TCP segment be the start of a new iSCSI PDU.
This would be especially valuable for data transfers, as
each segment would have enough information to place the data
in memory at the remote end.