Subject: [Tsvwg] Comments on draft-ietf-tsvwg-tcp-ulp-frame-00.txt

From: "Edward A. Gardner" <[email-masked]>
Date: Wed, 24 Oct 2001 17:05:53 -0600

Comments on draft-ietf-tsvwg-tcp-ulp-frame-00.txt

Summary:

1.  A PDU alignment mode with CRC should be defined.
2.  Add or expand discussion of receive exception processing.

1. A PDU alignment mode with CRC should be defined.

The introduction discusses how framing is intended to support the many ULPs
that perform bulk data transfer.  Each of those ULPs has or is adding a CRC
to augment the TCP checksum.  It would simplify hardware or software stack
design if all ULPs chose the same CRC, calculated it the same way, and
placed it in the same location.

In an ideal world we would add a CRC to the standard TCP header and retrofit
all past, present and future TCP implementations to support it.  As time
machines are beyond the state of the art that is not practical.

Almost as good is to include CRC checking in the framing headers.  With PDU
alignment mode we can do so with no additional overhead.  This might even
result in some traditional, streaming mode TCP applications enabling framing
simply to obtain the more robust CRC checking.

PDU alignment mode formats a framing PDU as:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Length               |             Key1              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Key2                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                                                               ~
     ~                           ULP PDUs                            ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposal 1a:

In PDU alignment with CRC mode the sender first constructs a PDU alignment
mode format framing PDU as currently described.  The sender then calculates
a CRC across the entire framing PDU -- first byte of length through last
byte of ULP PDUs.  It then stores the CRC in place of Key2 and transmits the
framing PDU as a TCP segment.  This assumes a 32-bit CRC.  Receiver checking
should be obvious.

The key is already used as a consistency check, a mechanism to discard the
segment or take an exception processing path.  Combining the key value with
the CRC of the rest of the frame maintains these characteristics.

I would further advocate making all framing PDUs a multiple of 4 bytes (the
CRC size), regardless of whether a CRC is present.

Some minor changes to the framing PDU format may make CRC processing
slightly more convenient.  Note that I would apply these changes to PDU
alignment mode both with and without CRC.

Proposal 1b:

Reverse the order of the framing header so that the CRC / Key2 are the first
longword in the frame:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Key2 / CRC                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Key1             |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                                                               ~
     ~                           ULP PDUs                            ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposal 1c:

Move the CRC / Key2 to the end of the framing PDU:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Length               |             Key1              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                                                               ~
     ~                           ULP PDUs                            ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Key2 / CRC                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I would choose proposal 1c because it seems more natural.  However I believe
the actual implementation differences between the three to be minor.  Note
that with CRC disabled (e.g. when using IPsec end to end) these all contain
the same 48 bit key as the current PDU alignment proposal, just positioned
differently.

Re choice of CRC algorithm.  The choice of CRC polynomial is not that
important, so long as we choose just one.  However it should be a straight
CRC.  That is, we do NOT play the trick of initializing the CRC generator to
all ones, then storing the complement of the CRC.  The effect of the
complements is to include the frame length in the CRC calculation.  However
we already include the Length field in the calculation.  Including the
length twice could lead to certain magic combinations where the two lengths
cancel, resulting in weaker CRC coverage.

The above begs the question of adding a CRC to marker mode.  My personal
preference would be to embrace that statement "It is expected that
ultimately PDU alignment mode will dominate."  That is, ignore marker mode.
But that might cause too much trouble.

The obvious solution is to expand the marker format by an extra longword to
hold a CRC.  The positioning of the CRC, relative to the non-marker text,
should be the same as the position chosen for PDU alignment mode.  That is:

Marker proposal 1a:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Next PDU Offset        |        Next PDU Offset        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              CRC                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                                                               ~
     ~                       Inter-marker octet stream               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Marker proposal 1b:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              CRC                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Next PDU Offset        |        Next PDU Offset        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                                                               ~
     ~                       Inter-marker octet stream               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Marker proposal 1c:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Next PDU Offset        |        Next PDU Offset        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                                                               ~
     ~                       Inter-marker octet stream               ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              CRC                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Again I prefer 1c, but think the actual differences are minor.

The CRC is calculated over the Next PDU Offsets and the Inter-marker octet
stream.  Note that the ULP will need to be aware of the marker interval to
make full use of this, since it may need to pad out the Inter-marker octet
stream.  But then the ULP already needed to be aware of this mode to
indicate ULP PDU boundaries.

2.  Add or expand discussion of receive exception processing.

The discussion of receive processing should be greatly expanded, focussing
on exception cases.  Without this there is serious risk of interoperability
problems.  A flow chart or similar method of describing an algorithm might
be appropriate.

Questions that need to be answered:

When may a TCP segment be directly placed.

When may / should / must a TCP segment be discarded (because the receiver
thinks it was corrupted in transit).

When must a TCP segment go through the normal re-assembly / re-order process
before being placed.  This is necessary when path MTU changes or the sender
enters emergency mode.  It probably means the receiver switches from a
direct-placement mode to an in-order mode.

When may the receiver resume direct placement after entering in-order mode.

I'm willing to work with the authors to add any or all of the above to
future versions.

Edward A. Gardner               [email-masked]
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907     719 210-7200 cell

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 24 Oct 2001 18:29:26 -0700

Edward,

May I also add there is an additional general omission from this proposed
encapsulation.  As iWarp, iSCSI, RPC, Ad Infinitum expect the ability to
place data chunks into user space, a general provision for doing so should
also be included.  This would mitigate the application unique packet filters
otherwise needed which destroy any concept of network layering.  If you
expect to be making a hardware acceleration of this modification to TCP,
then perhaps a few other features could be added.  One notable improvement
would be a payload identifier to allow compatible sharing of a connection
rather than delegating out a new list of ports for this new encapsulation.
One may even go so far as to adopt SCTP structures for doing so where Stream
is used as the general tag that can associate appropriately at the various
APIs together with parsing confirmation that the data is formatted as
expected via the Payload ID.  There would not be a need to invent undefined
signaling that steps around the transport as this encapsulation could be
defined as Son of SCTP or SOS for short.  :)

As far as CRC, the all ones initialization ensures proper processing of
leading zeros.

Doug

Summary:

Proposal 1a:

Proposal 1b:

Proposal 1c:

Marker proposal 1a:

Marker proposal 1b:

Marker proposal 1c: