RE: Framing Discussion

[Wayland Jeong <wayland@troikanetworks.com>]

I have a question regarding the single bit TCP option. Forgive me if this
has been described somewhere else, but I don't completely understand how
this works.

The single bit option in the TCP header will inform the receiver that a PDU
header is present in the current TCP segment. Furthermore, I believe that
this option also indicates that the PDU header is aligned with the current
segment (i.e. the header can be found at a known offset). This must be the
case since the option does not include a pointer to the location of the
header within the segment.

Now, here is my question. If you cannot make any guarantees regarding the
alignment of PDU's and TCP segments being sent from the originator, then how
can you make any assumptions about when you might get this alignment bit?
Let's take an example. A receiver TOE that is parsing iSCSI PDU's notices a
dropped TCP segment. The iSCSI TOE must abandon the current PDU being
re-assembled and attempt to find the next alignment point. Everything that
comes in off the wire between the dropped segment and the next aligned
segment must be squirreled off into NIC memory somewhere until the dropped
segment is re-sent. Now, one of the problems we are trying to solve is the
problem of supplying a large amount of high-bandwidth memory on the NIC in
order to save-off an RTT's worth of wire-speed data waiting for information
to perform re-alignment. If a generalized receiver cannot make an assumption
of when it might receive this alignment through the bit in the TCP options
part of the header, then, how do you avoid having this worst-case
re-assembly memory?

Now, it might be the case that the receiver assumes that the sender always
packages its PDU's aligned. In this case, some segments may be less that
MSS, but that's okay. Thus, the receiver is assured that it will receive the
aligned bit in the TCP header and thus the next aligned PDU within a PDU's
worth of TCP data. This is fine, but it requires that both the sender and
the receiver play nicely together. If this is the case, is it the assumption
that if this option was agreed upon during negotiation, then the receiver
can assume that the sender is going to both use this option and ensure
alignment? Also, what about things in the network that terminate TCP like
NAT's, firewalls and PEP's. Surely they cannot be expected to keep this
assumption regarding PDU alignment.

-Wayland