Subject: Re: [tsvwg] WGLC comments request for draft-ietf-tsvwg-rfc4960-errata-04.txt - to end Fri 8th Dec 2017

From: Michael Tuexen <[email-masked]>
Date: Sun, 4 Mar 2018 19:38:53 +0100

> On Dec 5, 2017, at 11:40 AM, Ka-Cheong Poon <[email-masked]> wrote:
> 
> On 11/17/2017 02:18 PM, Gorry Fairhurst wrote:
> 
>> As we discussed during the TSVWG session today, the draft "RFC 4960 Errata and Issues", is thought ready for publication and now ready for feedback. The latest version of the draft is available here:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc4960-errata-04
> 
Hi Kacheong,

thanks for your review. Please see my comments in-line.

Best regards
Michael
> 
> Some comments:
> 
> 3.6.2.
> 
> It may not be clear what "path currently is used for data
> transfer" is.  Does it mean that an SCTP impl can only use
> one path to send data?  What does it mean if an SCTP impl
> sends data to more than one path simultaneously?
RFC 4960 does not cover load sharing or CMT. We are not using
the term "primary path" since an implementation might use
a different different path if the primary becomes unavailable.
Please note that we are not using MUST, since you can implement
smarter ways of handling the counter...
> 
> 
> 3.17.2.
> 
> I remembered that there was a discussion on which addresses
> are considered to be confirmed when using sctp_connectx().
> The new text means that all the addresses passed to
> sctp_connectx() are considered confirmed.  But I remembered
Correct. That was the result of the discussion in the past and
is also the intention of the text.
> that the discussion argued for only the address used by the
> peer to send the INIT-ACK is confirmed.  Is this correct?
I think you are thinking about the passive side: Here RFC 4960 states:

   2)  For the receiver of the COOKIE ECHO, the only CONFIRMED address
      is the one to which the INIT-ACK was sent.
Please note that this is not the active side.
> 
> 
> 3.26.2.
> 
> o  SCTP MUST NOT increment cwnd by more than 1*MTU per RTT.
> 
> If MUST is used, this excludes other congestion control
> algorithms.  Is it better to use "SHOULD"?  This probably
> also applies to 3.27.2 (section 7.2.1).  But the original
> already uses MUST...
We are describing congestion avoidance here and are using
the same normative language as RFC 5681.
I don't think this will limit the evolution of other congestion controls.
> 
> 
> 3.31.2.
> 
> This sentence "When calculating the number of packets to transmit
> and particularly using the formula above, cwnd SHOULD NOT be
> changed" can be confusing regarding the following
> 
>    if((flightsize + Max.Burst*MTU) < cwnd)
>        cwnd = flightsize + Max.Burst*MTU
> 
> cwnd is set to a NEW value yet the sentence required that cwnd
> cannot be changed.  Maybe use another variable, eff_cwnd (effective
> cwnd) in the formula?
The statement is "SHOULD NOT be changed permanently". To stress this point
I added "temporarily" to
"The limit MAY be applied by adjusting cwnd temporarily as follows:"
> 
> 
> 3.40.
> 
> Just a question.  When the I-D.ietf-tsvwg-ecn-experimentation
> becomes an RFC later, will this be updated in this doc too?
> Or will the reference stay as an I-D?
The ID became already an RFC and I have updated the references
to RFC 8311:
https://github.com/sctplab/rfc4960bis/commit/1c46ddcd3b91cbcfd2096b46e087a55c6abc00c3
> 
> 
> 3.41.
> 
> Another question.  Should the Host Name Address parameter be
> completed removed from the doc instead of stating that it MUST
> not be used everywhere?  I found it very strange that a type is
> specified in the doc and then everywhere else states that it
> MUST not be used...
We discussed this and decided that it might be confusing to not
mention it... Therefore we kept the definition be state clearly
that its usage is deprecated.
> 
> If it has to stay, I guess RFC 4960 3.3.2.1 (where Host Name Address
> is first mentioned) should be updated to clearly state that it
> is deprecated.
It does already:

---------
Old text: (Section 3.3.2.1)
---------

The sender of INIT uses this parameter to pass its Host Name (in
place of its IP addresses) to its peer.  The peer is responsible for
resolving the name.  Using this parameter might make it more likely
for the association to work across a NAT box.

---------
New text: (Section 3.3.2.1)
---------

The sender of an INIT chunk MUST NOT include this parameter. The
usage of the Host Name Address parameter is deprecated.
> 
> 
> Thanks.
> 
> 
> -- 
> K. Poon
> [email-masked]
> 
>