Subject: questions/suggestions on <draft-ietf-ips-fcovertcpip-06.txt>

From: "Sharma, Suman" <[email-masked]>
Date: Wed, 3 Oct 2001 13:58:15 -0700

Hi,
  I am new member of this group. I just now went thru the FCIP draft. Have
some questions and suggestions about. I am very new to this so please
correct me if I have written anything wrong.

1. section 4->4) Class 1 FC frames( and some signals) are not transmitted
across an FCIP link. Since purpose of FCIP is to replace end-to-end fiber.
So, how these frames will be transfered ?

2. section 5.2 , fig.2 FCIP Link Model is little bit confusing. Instead of
writing FCIP on one side and Link on other side, it will be good if FCIP
Link is written both side.

3. section 5.6.2.1 and 5.6.2.2. If someone is doing TCP checksum validation,
is it required to do 5.6.2.2 checks ? At least test j) is not required ?

4. Once TCP payload will have only one FC frame or it can have multiple FC
frame ? Its not mentioned anywhere, but from the section 5.6.2.2 and 5.6.2.3
it seems to me that it can have multiple FC frame ? 

-suman

====================================
Suman Sharma
Sr. Network Software Engineer
Access & Switching Processor Division (ASPD) 
Intel Corporation
Phone: (408)545-6287
mailto:[email-masked]

---

From: Robert Snively <[email-masked]>
Date: Mon, 15 Oct 2001 15:58:20 -0700

> So, how these frames will be transferred ?

Class 1 is connection oriented and requires 100% guaranteed
bandwidth the whole length of the link.  TCP/IP cannot support
that behavior reliably.  This did not hurt anybody's feelings
because class 1 is principally a legacy implementation.

> 
> 2. section 5.2 , fig. 2 FCIP Link Model is little bit 
> confusing. Instead of

The intent here is that the IP network as well as the two
wires to the FC Fabric be interpreted as a single link.

> is it required to do 5.6.2.2 checks ? At least test j) is not 

The required checking is specified because the TCP checksum
validation (which of course is assumed to be present) has proven
less than perfectly reliable in some environments.  The tests
are required according to the explanations.  Verification of
length and length redundancy is required.  At least some other
verifications are a very good idea.

> it seems to me that it can have multiple FC frame ? 

There is no relationship between a TCP payload or segment and the
FC frame boundaries.  That is the nice thing about TCP.  It simply
delivers a string of reasonably well checked bytes in the proper
order and lets the upper layers choose what to do with them.
As a result, a TCP payload may have a fraction of a frame,
fractions of two frames, fractions of two frames and one or more
whole frames, exactly one whole frame, or multiple whole frames.
FCIP does not care, as long as the transmission of a TCP payload 
is not unduly held up waiting for enough information to make it
a certain size.  Realistically, I would expect that many implementations
will at least start a TCP segment on an encapsulated frame boundary, 
but only end on a frame boundary if there was no additional information to
throw into the segment, but that is NOT part of the architecture.