Re: Review of GIST over SCTP and DTLS - updated

Hi Xiaoming,

I have reviewed the draft and would like to see the following things 
fixed before we can conclude that the draft is ready to go forward:

- Introduction:
   * what are these "other issues" of TCP? Please clarify.
   * "...especially if deployment over the public Internet is 
contemplated": I don't quite get this statement. SCTP, as DCCP, does not 
natively get through firewalls (nor NATs), so SCTP is not directly 
applicable to the Internet at large, on the contrary.

- S3.4: s/"was able to remain"/"was able to retain"/

- 5.1: In practice the multihoming support of SCTP is not that 
beneficial. Since NSIS is about signaling on the data path, and if that 
data path fails, it doesn't really the application if the state can 
still be refreshed using an alternative path. The only benefit of 
multihoming might be that the state on the failed path can be more 
quickly torn down using the multihoming capability of SCTP. So, please 
be more clear on this, the current text goes back and forth on the topic.

  - 9. IANA section: name the MA protocol 4 differently, we could also 
have DCCP and DTLS. Thus, MA protocol 4 is DTLS over SCTP.

Regards,
Jukka

On 02/20/2010 02:49 PM, Xiaoming Fu wrote:
> Hi all,
>
> I have submitted a new version (v09), which has been verified by Elwyn
> to address his comments; it also fixed some other minor issues. Thanks a
> lot for Elwyn and other reviewers for your valuable inputs!
>
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-sctp-09.txt
>
> Cheers,
> Xiaoming
>
> Xiaoming Fu wrote:
>> Hi Elwyn,
>>
>> Thanks for your helpful comments. Feedbacks to your comments inline:
>>
>> Elwyn Davies wrote:
>>> Hi.
>>>
>>> Sorry this is bit late. I reviewed draft-ietf-nsis-ntlp-sctp-07.
>>>
>>> Comments:
>>>
>>> Header: I guess this has to be experimental now.
>>
>> Yes, fixed.
>>>
>>> Minor Issues:
>>> s2, next to last para: I don't think you can claim 'no changes to
>>> GIST'. The addition of SCTP and DTLS inevitably adds code to GIST, and
>>> some changes to the API are envisaged also. one might say:
>>> The methods of using an unchanged SCTP with GIST described in this
>>> document do not require any changes to the high level
>>> operation and structure of GIST. Addition of the new transport
>>> options require additional interface code and configuration
>>> support to allow applications to exploit the additional transport
>>> when appropriate.
>>
>> Yes, will include these text.
>>>
>>> s3.1.2: As with other SCTP applications, part of the point of SCTP is
>>> to conceal from the higher level application that a particular
>>> connection has died. SCTP should or might be able to keep roght on
>>> running using other address pairs even if one link dies. One shoudl be
>>> clear here just what sort of error is going to be reflected back to the
>>> NSLP. I am not sure what the socket interface for SCTP does in various
>>> citcumstances as I have never has the opportunity to make use of one.
>>
>> According to SCTP API specification
>> (http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket), errors will
>> be notified when detecting some problems and maybe notified via
>> SCTP_PEER_ADDR_CHANGE (, SCTP_SEND_FAILED or SCTP_REMOTE_ERROR
>> messages to the application. For multi-homing scenario, when a
>> destination address of a peer encounters a change, an
>> SCTP_PEER_ADDR_CHANGE message may be sent to the application, to
>> notify about the new primary address (primary path, in turn) or the
>> (un)availability of different addresses.
>>
>> If people agree, we can add a statement summarizing above to the ID.
>>
>> These will be in line with the GIST spec:
>> "an error MUST be indicated to the local signalling application
>> identifying the routing information for the message in question."
>> and complimenting with the notification when multihoming is applied.
>>
>>
>>>
>>> s5.1: Maybe one should discuss the meaning of path coupled in the face
>>> of multipath routing!
>>
>> Path-coupled signaling in this context is still valid: although
>> multiple possible paths may be detected, at one time there is only one
>> path as primary path per standard SCTP spec. Of course detecting
>> multiple paths and choosing which one to transport NSIS messages is
>> the job of SCTP itself, and GIST just needs to give SCTP instance with
>> the desired message. I think this is clear, thus there may be no need
>> for extra explanation.
>>
>>>
>>> Editorial:
>>> s1, para 2:
>>>> Furthermore, this document shows how GIST
>>>> SHOULD be used to provide the additional features offered by SCTP to
>>>> deliver the GIST C-mode messages
>>> This doesn't sound quite right. As with the point (in minor issues)
>>> about s1 (next to last para), GIST *does* have to be expanded to support
>>> SCTP and DTLS. and you are documenting how to use GIST when it has
>>> SCTP/DTLS support, so
>>
>> Yes, you're right.
>>>
>>> Furthermore, this document descibes how GIST should be interfaced
>>> to SCTP and used by NSLPs in order to exploit the
>>> additional capabilties offered by SCTP to deliver GIST C-mode
>>> messages more effectively.
>>
>> Thanks for your suggestion. will update.
>>>
>>> s1, last para: Do we describe SCTP as a datagram transport protocol? I
>>> thought it was more sequenced packet, but I may be wrong.
>>
>> We meant by DTLS is primarily a datagram secure protocol, but SCTP is
>> a mixture of streaming and datagram transport + other feature. What
>> about:
>>
>> " This document also specifies how to establish GIST security using an
>> extension to DTLS for use in combination with e.g., SCTP and UDP."
>>
>>>
>>> s2: Do we actually need to copy the definitions of MRM. MRI, MRS and
>>> SCD?
>>
>> We added in a recent version, due to the request from several WG
>> members in their reviews.
>>>
>>> s2, definition of SCTP Assocation: s/identified by the transport
>>> addresses/identified by the set of transport addresses/
>>>
>>> s3.1.1: Maybe mention that these go into the Stack Configuration Data.
>>>
>>> s3.2, para 2: s/bi-direction/bi-directional/
>>>
>>> s3.3, para 1: s/partial relaible messages/partially reliable messages/
>>>
>>> s3.3, para 2: s/In a standard SCTP../With standard basic SCTP[2]../
>>>
>>> s5.2: s/as transport GIST/as transport for GIST/
>>>
>>> s11.2 [9] The extensibility draft file name has changed.
>> Ok - will fix.
>>
>> Xiaoming
>>>
>>>
>>> _______________________________________________
>>> nsis mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/nsis
>>>
>>
>

-- 
Jukka MJ Manner, Professor, PhD.  Phone:  +358+(0)9+470 22481
Aalto University                  Mobile: +358+(0)50+5112973
Department of Communications      Fax:    +358+(0)9+470 22474
and Networking (Comnet)           Office: G320a (Otakaari 5A)
P.O. Box 13000, FIN-00076 Aalto   E-mail: [email protected]
Finland                           www.netlab.hut.fi/~jmanner/