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

From: Qiaobing Xie <[email-masked]>
Date: Fri, 1 Dec 2017 12:00:13 -0600

(re-send with tsvwg list)

> On Nov 27, 2017, at 11:05 PM, Qiaobing Xie <[email-masked]> wrote:
> 
> In 3.2., the new text still reads quite confusing to me.. maybe just directly says something like:
> 
> "Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST discard/ignore subsequent ULP shutdown requests, 
> but MUST continue to response to SHUTDOWN chunks from its peer.”
> 
> And a couple of minor fixes:
> 
>   O) Receive Unacknowledged Message
> 
>      Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer
>              size [,stream id] [,stream sequence number] [,partial
>              flag] [,payload protocol-id])
> 
> -Q
> 
>> On Nov 21, 2017, at 6:47 AM, Michael Tuexen <[email-masked]> wrote:
>> 
>>> On 21. Nov 2017, at 13:27, Irene Rüngeler <[email-masked]> wrote:
>>> 
>>> I reviewed this draft and found some typos which I mentioned to Michael directly. Otherwise, I have no comments concerning functional topics and support the progression of this draft to RFC.
>> Hi Irene,
>> 
>> thanks for the review.
>> 
>> The changes  have been committed and the changes are available at:
>> https://github.com/sctplab/rfc4960bis/commit/77823a3d065c716c4257e65e65dae995ad47ee22
>> 
>> Best regards
>> Michael
>>> 
>>> Best regards
>>> 
>>> Irene
>>> 
>>>> Am 17.11.2017 um 14:52 schrieb Michael Tuexen <[email-masked]>:
>>>> 
>>>> Dear all,
>>>> 
>>>> thank you very much for agreeing to review the ID during WG LC.
>>>> 
>>>> The WGLC has just started. I'm sending this mail since I'm not sure
>>>> you are following the tsvwg mailing list.
>>>> 
>>>> Please send your comments to the mailing list. In the unlikely event that
>>>> you don't have any comments, please state that in a short mail, too.
>>>> 
>>>> Thank you very much for your support!
>>>> 
>>>> Best regards
>>>> Michael
>>>> 
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: Gorry Fairhurst <[email-masked]>
>>>>> Subject: [tsvwg] WGLC comments request for draft-ietf-tsvwg-rfc4960-errata-04.txt - to end Fri 8th Dec 2017
>>>>> Date: 17. November 2017 at 07:18:35 CET
>>>>> To: [email-masked]
>>>>> Cc: [email-masked]
>>>>> Reply-To: [email-masked]
>>>>> 
>>>>> 
>>>>> Dear TSVWG WG,
>>>>> 
>>>>> 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
>>>>> 
>>>>> This email starts a 3 week WGLC to allow time for folks to provide feedback, to conclude on Fri 8th Dec 2017. Please send comments indicating the usefulness of the draft, noting issues, or simply asking for clariification to this list (or to the WG Dhairs).
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> Gorry, David and Wes
>>>>> (TSVWG co-Chairs)
>>>>> 
>>>>> The following people have agreed to also submit a review during the WGLC period:
>>>>> Kacheong
>>>>> Peter Lei
>>>>> Irene Rungeler
>>>>> Qiaobing Xie
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> *****************************************
>>> 
>>> Dr. Irene Rüngeler
>>> Fachbereich Elektrotechnik und Informatik
>>> Labor für Netzwerkprogrammierung, Datenbanklabor
>>> 
>>> Fachhochschule Münster
>>> - University of Applied Sciences - 
>>> Stegerwaldstraße 39, Raum E130a
>>> 48565 Steinfurt
>>> 
>>> Tel: +49 2551 962-561 
>>> Fax: +49 2551 962-563 
>>> EMail: [email-masked]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>

---

From: Ka-Cheong Poon <[email-masked]>
Date: Tue, 5 Dec 2017 18:40:35 +0800

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:

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?

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
that the discussion argued for only the address used by the
peer to send the INIT-ACK is confirmed.  Is this correct?

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...

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?

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?

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...

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.

Thanks.

-- 
K. Poon
[email-masked]