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

[Elwyn Davies <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/nsis