Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-03.txt

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Fri, 20 Mar 2015 11:29:45 +0100

HI,

Please accept the following comments to the SCTP section.

Generally I think that the section is extremely well written and touches
on the majority of
significant  SCTP transport service aspects.

I have some minor nits for consideration for the next update:

#1: Section 1, Second paragraph:

In the context of web-sockets over TCP and RTP over UDP one might refer to
RTCWEB data channel usage of SCTP, but I also recognize that this may not
strike the right balance towards the other more widely used services.

#2: Section 1, Third paragraph:

One could reformulate:

   for instance, SCTP offers a message-based
   service that does not suffer head-of-line blocking when used with
   multiple stream, because it can accept blocks of data out of order,

-->

   for instance, SCTP offers a reliable ordered message-based delivery
   service that, when used with multiple streams, mitigates the effects of
head-of-line blocking,
   because head-of-line blocking is confined to the individual stream.

One might even also, but not sure if this is equally important, rely to
that SCTP offers the service of reliable un-ordered delivery:

-->

   for instance, SCTP offers a reliable unordered message delivery which
does not suffer from head-of-line   blocking as well as a reliable ordered
message-based delivery
   service that, when used with multiple streams, mitigates the effects of
head-of-line blocking,
   because head-of-line blocking is confined to the individual stream.

#3: Section 3.3.1: Fourth paragraph. Bundling:

Would it be relevant to refer to that sender side bundling delay typically
is (or may be) implemented as Nagle bundling with an override timer ?
Further I think that it is important to distinguish this from bundling
delay from the standard bundling of immediately available messages for
efficiency reasons.

#4: Section 3.3.1: Fourth paragraph. PMTUD:

Should the text not refer also to RFC1191 and RFC1981. Possibly as:

ICMP-based PathMTU discovery [RFC1191][RFC1981]
   as well as Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821]
   are supported.
[RFC4821] defines a method to perform packetization layer path
   MTU discovery for SCTP with probe packets using the padding chunks
defined the
   [RFC4820].

#5: Section 3.3.1:  6th paragraph:
Perhaps one could elaborate:

Only all ordered messages sent on the same stream are
   delivered at the receiver in the same order as sent by the sender.

-->

Only ordered messages sent on the same stream are
   delivered at the receiver in the same order as sent by the sender.
Un-ordered messages (any stream) are delivered at the receiver in the
order they arrive, conditional to message reassembly having been
performed.

#6: Section 3.3.1: 6th paragraph: Schedular and prioritizations of
streams.

I think this could be a potential very important feature for SCTP (for
signaling) and that it deserves to be mentioned in its own right.
What about the following change:

[I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation and
   also allows to specify a scheduler for the sender side streams
   selection.

-->

[I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation.

[I-D.ietf-tsvwg-sctp-ndata] further allows to
  specify different stream schedulers for the sender side selection of
which streams to transmit from, thereby allowing for various priority
schemes for the sender side transmittal.

#8: section 3.3.1 second last paragraph:

I note that native NAT traversal is not mentioned even though this is a wg
document.
- ?

#9: Should SCTP AUTH not be described in an individual paragraph of
section 3.3.1 ?

#10: Section 3.3.2:

Perhaps reformulate:

One-to-one style sockets are similar to TCP sockets, there is a 1:1
   relationship between the sockets and the SCTP associations (except
   for listening sockets).  One-to-many style SCTP sockets are similar
   to unconnected UDP sockets as there is a 1:n relationship between the
   sockets and the SCTP associations.

-->

One-to-one style sockets are similar to TCP sockets, there is a 1:1
   relationship between the sockets and the SCTP associations (except
   for listening sockets).  The major difference to TCP is that the SCTP
associations can span multiple local and remote addresses.
  One-to-many style SCTP sockets have some similarity with
   unconnected UDP sockets as there is a 1:n relationship between the
   sockets and the SCTP associations endpoints.

#11: Section 3.3.3:

.	Perhaps one should extend the "reliable or partially reliable
delivery" to "reliable, partially reliable or un-reliable delivery"
.	I am a little unsure about the "unordered delivery within a
stream" - I know that one can read the stream that an ordered messages was
received from, but if that it enough to qualify for delivery "within a"
stream I am not sure.
.	Integrity check refers to checksum. In the TCP Transport Protocol
Components list this
is listed as error detection. One should use aligned semantics - I think ?
.	Should SCTP Auth not be mentioned ?
.	Is think flow control should simply be "flow control"  (no
reference to slow receiver).
.	I think  the support for multiple prioritized streams should be
split into two bullets:
o	Support for multiple concurrent streams
o	Support for stream scheduling prioritization
.	I would replace "application PDU" with "message"

BR, Karen

>-----Original Message-----
>From: Taps [mailto:[email-masked]] On Behalf Of internet-
>[email-masked]
>Sent: Friday, February 27, 2015 1:52 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [Taps] I-D Action: draft-ietf-taps-transports-03.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Transport Services Working Group of the
IETF.
>
>        Title           : Services provided by IETF transport protocols
and congestion
>control mechanisms
>        Authors         : Godred Fairhurst
>                          Brian Trammell
>                          Mirja Kuehlewind
>	Filename        : draft-ietf-taps-transports-03.txt
>	Pages           : 25
>	Date            : 2015-02-27
>
>Abstract:
>   This document describes services provided by existing IETF protocols
>   and congestion control mechanisms.  It is designed to help
>   application and network stack programmers and to inform the work of
>   the IETF TAPS Working Group.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-taps-transports/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-taps-transports-03
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03
>
>
>Please note that it may take a couple of minutes from the time of
submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>Taps mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 21 Mar 2015 17:32:14 -0500

Hi Karen,

thank you very much for the review. See my comments in-line.

Best regards
Michael

> On 20 Mar 2015, at 05:29, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI,
> 
So what about:
Transport services
may be provided directly by these transport protocols, or layered on top
of them using protocols such as WebSockets (which runs over TCP), RTP
(over TCP or UDP) or WebRTC data channels (which run over SCTP over DTLS
over UDP or TCP).
>   because head-of-line blocking is confined to the individual stream.
What about:
SCTP offers a message-based service providing full or partial reliability
and allowing to minimize the head of line blocking due to the support of
unordered and unordered message delivery within multiple streams, ...
> is (or may be) implemented as Nagle bundling with an override timer ?
I wouldn't say that it is typically implemented with an override timer...
My point was that SCTP has specific mechanisms for supporting small messages
efficiently and also large messages.
> delay from the standard bundling of immediately available messages for
Hmm. The section describes the protocol. So I don't want to go into too
much detail. So what about adding the following sentence:

For example, this bundling may be done by delaying user messages at the sender
side similar to the Nagle algorithm used by TCP.
>   MTU discovery for SCTP with probe packets using the padding chunks
What about:
ICMP-based path MTU discovery as specified for IPv4 in {{RFC1191}} and for IPv6
in {{RFC1981}} as well as packetization layer path MTU discovery as specified in
{{RFC4821}} with probe packets using the padding chunks defined the {{RFC4820}}
are supported.
> order they arrive, conditional to message reassembly having been
I'm not sure this is really guaranteed by the specs. I think unordered
messages can be delivered in the order they arrive, but don't have to be.
So what about changing it to

User messages can be sent un-ordered or ordered upon request by the upper layer.
Un-ordered messages can be delivered as soon as they are completely received.
Only all ordered messages sent on the same stream ...

> schemes for the sender side transmittal.
What about
{{I-D.ietf-tsvwg-sctp-ndata}} overcomes this limitation.
Furthermore, {{I-D.ietf-tsvwg-sctp-ndata}} specifies multiple algorithms for
the sender side selection of which streams to send data from supporting a
variety of scheduling algorithms including priority based ones.

> I note that native NAT traversal is not mentioned even though this is a wg
Good point. I missed that one. So what about adding at the beginning of
the paragraph:

{{I-D.ietf-tsvwg-ietf-tsvwg-natsupp}} defines a methods for end-hosts and
middleboxes to provide for NAT support for SCTP over IPv4.

> #9: Should SCTP AUTH not be described in an individual paragraph of
The TCP MD-5 option is not discussed, so I thought describing SCTP-AUTH
as a service might not be worth. It is used in combination with DTLS and
dynamic address reconfiguration. Do you see a relevant use case for
SCTP-AUTH on its own?
>   sockets and the SCTP associations endpoints.
Well, multihoming-support is not related to the socket style. This is
covered by an extra paragraph.
> delivery" to "reliable, partially reliable or un-reliable delivery"
I don't use un-reliable, since I don't know what it is. What is the
difference between un-reliable and partial-reliable. Bot are versions
of not being reliable.
> received from, but if that it enough to qualify for delivery "within a"
Well, this is my understanding: A sender selects
* an outgoing stream
* whether the message is sent ordered or unordered
Both is presented in the API to the receiver. So I think the text is appropriate.
> is listed as error detection. One should use aligned semantics - I think ?
That is correct. Maybe
Strong error detection (CRC32C)
to emphasis that it is not "just" the normal checksum.
> .	Should SCTP Auth not be mentioned ?
Depends on the point above...
> reference to slow receiver).
Correct.
> o	Support for stream scheduling prioritization
OK.
> .	I would replace "application PDU" with "message"
Changed to user message.

Thanks a lot for you comments. They help to improve the SCTP test substantially!