RE: FCIP - comments on draft-ietf-ips-fcovertcpip-00.txt

[Vi Chau <vchau@gadzoox.com>]

Randall,

    Thank you for your insight and your fair and accurate analysis
of the draft. We in the editing group are working to address the
issues that you have raised here.


Vi Chau
Gadzoox Networks, Inc.
16241 Laguna Canyon Road, Suite 100
Irvine, CA 92618-3611
949-789-4639



> -----Original Message-----
> From: Randall R. Stewart [mailto:randall@stewart.chicago.il.us]
> Sent: Friday, November 03, 2000 4:12 AM
> To: SCSI over IP
> Subject: comments on draft-ietf-ips-fcovertcpip-00.txt
> 
> 
> 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)
>