Subject: [NSIS] Review of GIST over SCTP and DTLS - updated

From: Elwyn Davies <[email-masked]>
Date: Wed, 10 Feb 2010 20:10:40 +0000

Hi.

Sorry this is bit late.  I reviewed draft-ietf-nsis-ntlp-sctp-07.

I forgot that Jukka requested views on the value of the work and reasons for
further work.

I would say that SCTP could well have value in the early deployment situation.
If NSIS nodes were only available at the edge of enterprise networks, an SCTP
connection between two such boxes across the backbone might be interesting.  The
multi-path, multohoming support would then give reliability and help with
providing alternative routes that might not be otherwise discovered.

The advantages of SCTP in a more dense network of NSIS nodes is to my mnd a bit
dubious, but if there is a lot of traffic the streaming stuff and the multiple
connections could well be hlpful.

I am not sure how much SCTP has been deployed in general purpose machines.  If
SCTP deployment is not going places, I'm afraid that adding NSIS is not really
going to be the killer app that drives increased SCTP deployment.  In this case
the work needed to finish this may be of not much value.  On the other hand,
there doesn't seem to be a lot of work needed to get the draft ready.

Comments:

Header: I guess this has to be experimental now.

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.

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.

s5.1:  Maybe one should discuss the meaning of path coupled in the face
of multipath routing!

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

     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.

s1, last para: Do we describe SCTP as a datagram transport protocol?  I
thought it was more sequenced packet, but I may be wrong.

s2:  Do we actually need to copy the definitions of MRM. MRI, MRS and SCD?

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.

_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 16 Feb 2010 19:46:20 +0100

Hi Elwyn,

Thanks for your helpful comments. Feedbacks to your comments inline:

> Header: I guess this has to be experimental now.

Yes, fixed.
>     support to allow applications to exploit the additional transport

Yes, will include these text.
> 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

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.

> SCTP and DTLS.  and you are documenting how to use GIST when it has

Yes, you're right.
> messages more effectively.

Thanks for your suggestion. will update.
> 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.
> s11.2 [9]  The extensibility draft file name has changed.
Ok - will fix.

Xiaoming

-- 
Xiaoming Fu, http://user.informatik.uni-goettingen.de/~fu

---

From: Xiaoming Fu <[email-masked]>
Date: Sat, 20 Feb 2010 23:49:55 +0100

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