comments on draft-ietf-ips-fcovertcpip-00.txt

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Dear all:

I have finally taken a bit of time to look over this document
and I have some deep concerns in the way this draft attempts
to frame FC messages in TCP.

In particular two sections stand out has problems:
In section 4.2
"
     11. The TCP layer in  the sending FCIP device shall  package each
         FC frame handed  down by the FC  layer into a TCP segment and
         set the PSH control flag in the TCP header to ensure that the
         entire FC frame  is sent in one TCP segment.  If the FC frame
         cannot be packaged in one TCP segment (e.g. the FC frame size
         is greater than TCP MSS),  the last part of the FC frame must
         occupy  one TCP segment  and the PSH of that segment  must be
         set.
"
Ok, here you are attempting to use the PSH bit has a record marker.
This is NOT what is defined in TCP and it is not even required
to support this option. Please see my earlier post of RFC1122.txt.

This explictly states NOT to do what the above section defines.

In section 5.3 it states:
"
     5.3 FC frame mapping to TCP Segment

     The FC-to-TCP mapping  (and reverse mapping) may not  necessarily
     be one-to-one  as the FC frame  size may exceed the  TCP  Maximum
     Segment  Size (MSS).  In this case,  the TCP layer in the sending
     FCIP device may segment the  FC frame into multiple TCP segments.
     The sending device must ensure that the last TCP segment contains
     only the last part of the encapsulated FC frame and that last TCP
     segment does not contain the  beginning of another FC frame.  The
     last  TCP  segment  must also have  the PSH flag  set so that the
     receiving FCIP  device  knows to send the  frame to  the FC layer
     above  it.  The fields in  the TCP  header are  explained  in the
     following paragraphs:
"
The above paragraph puts a constraint on TCP to attempt to constrain
it to send just the partial segment. The above paragraph is in direct
conflict with RFC1122 i.e.:

I quote from RFC1122:
"
            The PSH bit is not a record marker and is independent of
            segment boundaries.  The transmitter SHOULD collapse
            successive PSH bits when it packetizes data, to send the
            largest possible segment.

"

What this is saying is that in any congestion situation, where you
cannot send the PSH bit's on sucessive sends will be collapsed.

And on top of all that has it further states in RFC1122 under the 
PUSH/PSH functionality:
"
                                                 |        | | | |S| |
                                                 |        | | | |H| |F
                                                 |        | | | |O|M|o
                                                 |        | |S| |U|U|o
                                                 |        | |H| |L|S|t
                                                 |        |M|O| |D|T|n
                                                 |        |U|U|M| | |o
                                                 |        |S|L|A|N|N|t
                                                 |        |T|D|Y|O|O|t
FEATURE                                          |SECTION | | | |T|T|e
-------------------------------------------------|--------|-|-|-|-|-|--
                                                 |        | | | | | |
Push flag                                        |        | | | | | |
  Aggregate or queue un-pushed data              |4.2.2.2 | | |x| | |
  Sender collapse successive PSH flags           |4.2.2.2 | |x| | | |
  SEND call can specify PUSH                     |4.2.2.2 | | |x| | |
    If cannot: sender buffer indefinitely        |4.2.2.2 | | | | |x|
    If cannot: PSH last segment                  |4.2.2.2 |x| | | | |
  Notify receiving ALP of PSH                    |4.2.2.2 | | |x| | |1
  Send max size segment when possible            |4.2.2.2 | |x| | | |
                                                 |        | | | | | |
"

The only MUST here is that a sender MUST set the PSH bit on the
last segment it has inqueue.

Now this draft will just plain NOT work with standard TCP
implemenations.
What it is requiring is that you modify TCP to make TCP work
for FiberChannel. 

Now I know that many of these devices may be custom built but I
do not think this WG has a charter that will include requirments to
change TCP.

You will need to re-address this section in the document. I would
suggest
either writting a 2 byte value down the TCP first containing the size
(in network byte order) followed by the actual FC frame ... or if
there is some size element within the FC header that could be looked
at by the TCP reader this could be used for framing... 


Has this draft is currently defined I just can't see it working. If one
were to use a standard TCP that is out there today, oh yes it would
work in many situations.. but the minute you hit a congestion situation
OR some network event, the PSH bit would most likely be collapsed 
amongst multiple TCP segements.... and then you would have no 
idea where the fiber channel frame is...

The only other alternative I could see you might want to attempt to
use is RFC2960 (as Doug as mentioned).


Regards

R

-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222 (cell) 815-477-2127 (work)