Re: [tsvwg] WGLC Follow-Up: draft-ietf-tsvwg-sctp-dtls-encaps

[Michael Tuexen <[e-mail]>]

On 24 Jun 2014, at 15:28, Gorry Fairhurst <[e-mail]> wrote:

> The WGLC for the above document ended 28th February 2014, and follow-up discussions resulted in a revised draft.
> 
> I am now starting to prepare for submission of the above document for requested publication. Please find detailed comments/questions about the text below.
Thank you very much for your comments. See my answers in-line.

Best regards
Michael
> 
> Best wishes,
> 
> Gorry Fairhurst.
> (TSVWG Co-Chair)
> 
> ---
> ABSTRACT:
>   "Using
>   encapsulation method described in this document, SCTP is..."
>  ^
> - insert /the/ ?
Done.
> 
> 
> ---
> ABSTRACT:
>  "As a consequence, the SCTP associations are single homed."
> - This final statement is not clear, although true. Please add text to explain to the reader why this is needed in the abstract. Could you say something that follows this below, and also explain why in section 6.1?
Not sure why the conclusion is not clear. How would you setup a multihomed
SCTP association without using IP addresses in control chunks (INIT/INIT-ACK/ASCONF)?
> "The security properties of this encapsulation limit usage to single-homed SCTP associations."
> ---
> Section 5:
>   "a safe value for the path MTU has to be used by the SCTP stack."
>   - How do you choose? - please specify a default or a method.
The data channel document specifies 1280 for IPv6 and 1200 for IPv4.
The IPv4 values was chosen based on experience by some WG members.
I can put the numbers in this document, if you want.
> ---
> Section 5:
>   "Differentiated services code point (DSCP) "
>   - reference needed.
I added a reference to RFC 2474.
> ---
> Section 5:
>   "explicit congestion notifications (ECN)"
>   - reference needed.
Added a reference to RFC 3168.
> ---
> Section 5:
>   "SCTP performs segmentation and reassembly based on the path MTU.
>   Therefore the DTLS layer MUST NOT use any compression algorithm.
> 
>   The DTLS MUST support sending messages larger than the current path
>   MTU.  This might result in sending IP level fragmented messages."
>   - I wonder if some reordering of paras within teh section could
>   gather all the size-related topics in one part of the section?
Makes sense. I moved them up.
> ---
> Section 6:
>   - I am surprised this section does not mention how to handle
>   any path changes, should PMTUD be triggered following known changes,
>   for instance? Does this affect the SCTP CC state?
The data channel document contains:

The ICE/UDP layer can handle IP address changes during a session without needing
interaction with the DTLS and SCTP layers.
However, SCTP SHOULD be notified when an address changes has happened.
In this case SCTP SHOULD retest the Path MTU and reset the congestion
state to the initial state.
In case of a window based congestion control like the one specified in
<xref target='RFC4960'/>, this means setting the congestion window and
slow start threshold to its initial values.</t>

So I added a bullet:

<t>If the SCTP is notified about a path change by its lower layers,
   SCTP SHOULD retest the Path MTU and reset the congestion state to the
   initial state. In case of a window based congestion control like the one
   specified in <xref target='RFC4960'/>, this means setting the congestion
   window and slow start threshold to its initial values.</t>

Does this address your issue?
> ---
> Section 6.1:
>    /doesn't deal/does not deal/
>    - please change.
Done.
> ---
> Section 6.1:
>   "All SCTP associations are single-homed."
>   Could you add something like:
>   ", because DTLS does not expose any address
>   management to its upper layer."
Done.
> ---
> Section 6.2:
>  "The padding extension defined in [RFC4820] MUST be supported and used
>   for probe packets when performing path MTU discovery as specified in
>   [RFC4821]."
> - Is this section relevant when DTLS implements PMTUD, please explain?
I added "by the SCTP layer".
> ---
> References:
> A later version (-10) exists ofdraft-ietf-rtcweb-overview-09
> A later version (-10) exists of draft-ietf-rtcweb-data-channel-08
They will be updated when submitting a new revision.
> ---
> The requirement to use SCTP/DTLS appears to also be cited in draft-ietf-rtcweb-overview-09, section 5.5, which requires normative use of SCTP/DTLS, but this document is not cited in the current document, I think it should be, if not why not?
It is cited as the first ID in
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-04#section-10.2
> 
> 
> 
> 
>