Subject: Re:draft-otis-fc-sctp-ip-00.txt

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 24 Aug 2000 08:47:05 -0500

Greetings:

(I apologize for the earlier subscribe mis-send... I should
 know better than to do anything before a second cup of
 coffee in the A.M. :->)

I have just finished reading both the above mentioned draft
and the draft - draft-ietf-ipfc-fcoverip-02.txt

I think that Douglas did a nice job of summarizing some of
the benefits that FC over SCTP/IP can gain in this draft
i.e.:

      - Headers contained within one frame. 
      - Objects aligned at 32-bit boundaries. 
      - Out of sequence frame processing. 
      - Standard authentication. 
      - Independent streams under common control. 
      - Session restart. 
      - Improved error detection. 
      - Prevention of blind spoofing and denial of service attacks. 
      - Standard Heartbeat and multi-homing. (optional) 

One other things not mentioned was:

      - Congestion control

Now after reviewing the ipfc-fcoverip draft particularly the
section that specifies why TCP should not be used, there may
be objections to the Otis draft...

One of problems mentioned in ipfc-fcoverip is the retransmission
by TCP being in conflict to retransmissions that would occur
at the FC level. I would like to call your attention to a
draft that I think will solve this problem... 

http://search.ietf.org/internet-drafts/draft-xie-stewart-usctp-00.txt

This draft defines a new extension that we have proposed for SCTP
that allows a particular stream to be specified has "no retransmission".
This way you can mix both completly reliable and unreliable
transmissions
over the same association AND still maintain correct congestion control
policy's in the network. We still are debating the addition of
a couple of things to this draft:

   - Should we have the ability to turn off checksums on selected
     data portions traveling on a stream. This way one could disable
     the alder-32 checksum on a unreliable stream packet but not
     the header, control,  or any reliable data.

   - How do you handle larger than the P-MTU sized messages? Currently
     the draft dis-allows this since when sending to an unreliable
stream
     you can never re-assemble the larger packet if a piece of one
     is lost. We may want to think about adding the ability to still
     fragment and hook in a mechanism to the reliable re-assembly queues
     to discard in-complete reassembly's where some datagrams are
     dropped due to the unreliable transmission. This would be
desireable
     to keep from having to do a double P-MTU discover (one at the 
     SCTP layer and the other at the IPFC layer).

We would appreciate any comments on the draft and I would be more
than glad to present either here on the mailing list or in San Diego
a short overview of both SCTP or SCTP-U if this is helpful... 

Thanks for your time and I would welcome any comments or questions..

R
-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222