Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-udp-encaps-03

[Michael Tuexen <[e-mail]>]

Hi Brian,

see my comments in-line.

Best regards
Michael

On Apr 24, 2012, at 1:35 PM, Brian Trammell wrote:

> Greetings, all,
> 
> Apologies for missing the WGLC end on this draft; however as it appears it may be rev'd anyway on the MTU DF question, I hope the following comments prove useful.
> 
> I've reviewed the document. It fills a need and the approach makes sense, so I'm in favor of its publication. I do have a couple of suggestions for clarification, though none of these change the normative content of the document. I'll state that my perspective here is as an SCTP application developer, and as someone interested both in this draft and draft-tuexen-tsvwg-sctp-dtls-encaps within the context of IPFIX over SCTP. (I'll also state that I didn't follow the WG discussion on this draft to date, as I only sporadically pay attention to tsvwg, so apologies if some of these comments are old news.)
Why do you prefer IPFIX over SCTP over DTLS over UDP compared to IPFIX over DTLS over SCTP over UDP?
> 
> I'm still a little confused about how exactly UDP port mappings to SCTP associations are meant to work in practice. Clearly, there is one UDP port per "stack": one per application with application-bound SCTP-over-UDP and one per host, defaulting to 9989, with SCTP-over-UDP in the kernel or via a (probably privileged) userspace SCTP-over-UDP daemon. This point might be made more clearly in section 4.1 -- that there are really two envisioned deployment scenarios (or three, depending on how you count), and explicitly spelling out the recommended port numbering for each.
Each SCTP stack running in userland will use its own UDP port number for receiving the packets.
Each stack will then use the SCTP port number for multiplexing/demultiplexing the packets
belonging to different associations.
> 
> (This opens an issue at the user interface level, though I am reasonably certain this is out of scope for this document. Now you potentially have one port that is exposed to the user or inherent to the application (the SCTP port), plus one port that may have to be exposed to the client or not based on the deployment scenario in use at the server. There are ways for dealing with this with a single port in user- or administrator-exposed names (URIs, DNS SRV...) but I don't know how well this works for two ports. 
> Again, I'm not sure it fits in this document at all, but some discussion of this issue (and suggested solutions) somewhere would keep each application developer or specifier of application protocols from having to solve it themselves. This issue would appear to apply to draft-tuexen-tsvwg-sctp-dtls-encaps as well.)
I guess this is not within the scope of the document.
> 
> There are a couple of other bits that were terse to the point of being a little unclear on a first reading. In section 4.2 it may be helpful to point out that the point of UDP checksumming is to reduce the chance of UDP header corruption. (I had
And UDP checksum is required for IPv6... However, the MUST will be changed to a SHOULD. On FreeBSD we
will just use the system wide setting for UDP/IPv4.
> to think about this for a couple of seconds; SCTP has its own reliability mechanisms, after all...) Likewise, section 4.8 might benefit from a note that you're talking about ECN bits in the IP header, and that ECN over SCTP works otherwise as specified in draft-stewart-tsvwg-sctpecn (with an informative reference).
I didn't wanted to add another reference. Just wanted to make sure that encaps/decaps should try to
transfer the ECN stuff. However, I have to double check if that is possible with the socket API on
plattforms like FreeBSD, Linux, Mac OS X using the socket API and Windows using whatever they provide.

Thanks a lot for the comments!

Best regards
Michael
> 
> Best regards,
> 
> Brian