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

[Matt Wakeley <matt_wakeley@agilent.com>]

I agree with Randall.

Simply put, TCP is a byte stream, and you cannot dictate to TCP what will or
will not be in a "TCP segment".  As far as the application layer above TCP is
concerned, there is no such thing as a tcp segment.  And neither the Push nor
Urgent options help.

Section 5.2 also talks about IP fragments, which is a BAD thing to do to TCP -
it results in performance hits.

You will need a "header" that will if nothing else indicate the length of the
FC frame.

-Matt Wakeley

"Randall R. Stewart" wrote:

> 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)