Subject: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to conclude Monday, July 21st, 2014

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 03 Jul 2014 09:45:46 +0100

This is the start of the WGLC on "Additional Policies for the Partial 
Reliability Extension of the Stream Control Transmission Protocol" for 
publication intended as a PS.

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-prpolicies/

This WGLC will last until Monday, July 21st, 2014 (longer since this 
includes time prior to an IETF meeting).

Could people please send *any* comments to the list if they think this 
is ready to publish?

A good note is "I have read this version of the draft,
and I approve (or support) its progression to RFC".

James/Gorry/David
TSVWG chairs

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 3 Jul 2014 19:34:04 -0600

Gorry,

Please see comments below:

Gorry Fairhurst wrote:                           (Thu, 03 Jul 2014 09:45:46)
> and I approve (or support) its progression to RFC".

I have read this version of the draft; however, I have some
comments:

It appears that the document only has about 3 (or 4) normative
paragraphs.  Of those three (or 4) paragraphs the key word
"REQUIRED" is used once with reference to RFC3758; the key word
"MUST" is used once with regard to abandoning a user message that
would exceed a retransmission limit.  There are two "MAY" and one
"OPTIONAL" key words.  The rest of the document is informational.

I question the sole "MUST" in section 3.1.  The most I think it
should be is a "SHOULD" and it should probably just be a "MAY".
Other considerations could go into whether to abandon or simply
postpone a retransmission that achieve the same effect.  Perhaps
what is attempted here is to say that "after a message has reached
its retransmission limit, the sender SHOULD NOT retransmit the
message again at the exclusion of resources to other messages
available for transmission or retransmission."  I do not see why you
would want to abandon retransmissions of messages on otherwise idle
associations: it would unnecessarily lower the reliability of the
association.

Also, when the sender is to abandon the message, it should likely
only be on the event of a timer-based retransmission request.  A
sender can get all kinds of spurious fast-retransmission requests
resulting in the discard of an excessive number of messages under
the current policy.  In fact, abandoning messages _in_itself_ is
likely to cause additional spurious gap reports and
fast-retransmission.  However, abandoning on a timer-based
retransmission would make the policy hardly distinguishable on the
wire from the existing lifetimes-based PR policy.

In summary, it seems to me that the document simply asks us to
implement some loose definition of a sender-side only API that does
not describe anything that "is required for interoperation or to
limit the behavior which has potential for causing harm" as required
by RFC 2119.  It seems to abuse the only normative MUST in the
document applied to a sender-side procedure that appears to not to
have been given much careful consideration.

The entire document appears more focused on the INFORMATIONAL
section 4 than on the NORMATIVE section 3.

As such, I object to it being published as a PS.  I would support
the draft being published as an INFORMATIONAL RFC if the procedure
described in section 3.1 is properly revised.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 6 Jul 2014 21:05:10 +0200

> I have read this version of the draft; however, I have some
Hi Brian,

thanks for reading the document and providing feedback.
See my comments in-line.

Best regards
Michael
> "MUST" is used once with regard to abandoning a user message that
MUST appears two times...
> should be is a "SHOULD" and it should probably just be a "MAY".
There are two MUSTs here. This first one is the one you refer to,
I think. The second one needs to be a MUST even if you downgrade the
first one to SHOULD.
> associations: it would unnecessarily lower the reliability of the
The user point is what the upper layer expects if he limits the
number of retransmissions. Your interpretation would be:
* When the number of retransmissions exceeds the threshold, the
  SCTP implementation is free is abandon the message.
The intended semantic used in this document is
* When the number of retransmissions exceeds the threshold, the
  SCTP implementation abandons the message.
This is in-tune with the semantic used by the RTCWeb WG.
> wire from the existing lifetimes-based PR policy.
I think one of the most important limits is 0. Here the upper layer does
not distinguish between timer based or fast retransmissions.
> have been given much careful consideration.
The intended status was changed from Informational to PS because
* the second MUST as described above.
* without normative language you can make sure that the upper
  gets what he expects.
This might not affect interoperability at the SCTP layer, but does
influence the upper layer.
> section 4 than on the NORMATIVE section 3.
Section 4 is longer, that is right. But the focus is not there.
If you don't case about the socket layer, section 4 is not important
to you.

---

From: "Karen E. Egede Nielsen" <[email-masked]>
Date: Sun, 20 Jul 2014 15:54:22 +0200

HI,

I support the extensions of the PR function as defined in the document.
I support the work as moving forward as PS. RFC3758 is PS and I do not see
that the new policies
defined pose any new issues compared to the policy already defined in
RFC3758.

(I actually do have some petty issues with the text of  RFC3758,
but these issues are equally applicable to the existing policy of
RFC3758 as to the new proposed ones. I will send these comments later.)

In respect to the technical scope presently in the document, then I think
that the text of the document is in a state ready to publish.
I have the following 2 comments to the scope of function as it is right
now.

#1: Given that we now have multiple PR policies, potentially applicable
within the same
SCTP association (but likely same policy on all messages within same
stream, e.g., media stream/data channel),
then I think that it would be relevant to have the stats in the
sctp_prstatus  be reported on a per policy basis.
Meaning that the socket option sctp_prstatus  should be extended to make
this differentiation.

#2: I note that the socket api handing specified in the document for
 control of whether to attempt to negotiate the function or not, does
 not adequately handle how to control the operation during restarts
(INIT from remote side) of an existing association. However this is a
general issue of the socket api  as specified in RFC6458 and as it is
not particular to the PR function, but general to all negotiable
features.  I thus recognize that be better addresses in an possible
follow up of RFC6458. Whether it be handled as a special purpose
 function to control the operation via-a-vis negotiable features
generally at remote restart of existing association or whether it
comes in as a general extension of all the particular functions
controlling a negotiable feature.
The issue is relevant for SCTP implementations in deployment and is
 today addressed  (at least by some implementations I know of) by
 proprietary means outside of (but somewhat in interworking with) the
socket api.

 BR, Karen

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: 3. juli 2014 10:46
> To: [email-masked]; [email-masked]
> Subject: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-prpolicies-03 - due to
> conclude Monday, July 21st, 2014
>
Reliability
> Extension of the Stream Control Transmission Protocol" for publication
> intended as a PS.
>
includes
> time prior to an IETF meeting).
>
is
> ready to publish?
>
> A good note is "I have read this version of the draft, and I approve (or
> support) its progression to RFC".
>
> James/Gorry/David
> TSVWG chairs

---

From: "Becke, Martin" <[email-masked]>
Date: Sun, 20 Jul 2014 14:18:49 +0000

> I support the extensions of the PR function as defined in the document.

+1

Best, 
Martin

---

From: Irene Rüngeler <[email-masked]>
Date: Mon, 21 Jul 2014 09:48:55 +0200

Hi,

I have read this version of the draft and support its progression to RFC.

Best regards

Irene

Am 03.07.2014 um 10:45 schrieb Gorry Fairhurst <[email-masked]>:

> This is the start of the WGLC on "Additional Policies for the Partial Reliability Extension of the Stream Control Transmission Protocol" for publication intended as a PS.
> 
> This WGLC will last until Monday, July 21st, 2014 (longer since this includes time prior to an IETF meeting).
> 
> Could people please send *any* comments to the list if they think this is ready to publish?
> 

*****************************************

Dr. Irene Rüngeler 
Fachhochschule Münster, Abt. Steinfurt 
FB Elektrotechnik und Informatik 
Labor für Netzwerkprogrammierung, Datenbanklabor 
Bismarckstr. 11 
Tel.: 02551-962561 
Fax: 02551-962563 
EMail: [email-masked]