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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

HI,

Please accept the following comments.
Use them as/if you see fit.
(Given my wretched, non-twistable, arms you are allowed not to take them
too seriously)

Section 3.1.1:

6'th paragraph:

" In addition, a congestion control
   mechanism may react to changes in delay as an early indication for
   congestion."

I think one will need to give a reference to this as it is not covered by
the reference to RFC5681.
Possibly this statement is better given in the context of the next
paragraph referring to extensions.

[I am aware that I have given this comment before. The reason that this
continues to be an issue for me is that
delay based CC alg's also are applicable to, e.g., SCTP (and have been
applied there, though I don't know much
about real deployment of them for SCTP).
I am not sure if the solution to this is to have a special common section
about congestion control algorithms - referring possibly
to that these special CC als mostly are in deployment for TCP].

9'th paragraph:

Reference to push flag:

The sentence:

"TCP provides a push and a urgent function to enable data to be
   directly accessed by the receiver without having to wait for in-order
   delivery of the data."

Should be revised I think. It is not very clear what the push flag
contribute with in this sentence. The PUSH flag helps to release a "tail"
packet from a  TSO/GRO function/temporary packet buffering function. This
feature of TCP might be significantly enough to describe the
PUSH flag function as an implicit and internal protocol implementation
optimization making TCP "push" tails through
intermediate buffering functions. But the PUSH function is not really a
"function" that TCP stacks provide to the ULP today
(even if this is described as an optional possibility in RFC1122) - Or is
it ?

The urgent flag is not recommended ... so does it belong here ?

Section 3.3:

1'st Paragraph:

I propose to remove the sentence:

"It also optionally supports path failover to
   provide resilience to path failures."

There is no optionality about it  and I think it is covered in the
sentence before on supporting MH
to handle path failures.

In sentence:

"An SCTP association has
   multiple unidirectional streams in each direction and provides in-
   sequence delivery of user messages only within each stream."

^^^
I propose to remove the word "only".

I suggest to add the following sentence:

"SCTP supports multiple stream scheduling schemes controlling the
multiplexing of the streams
into the transmission channel. Including priority as well as fair
weighting schemes."

Section 3.3.1:

I propose to add the following sentence in the end of the paragraph on
multi-homing below the bulleted list:

"[I-D.ietf-tsvwg-sctp-failover] specifies a quicker failover operation
reducing the latency of the failover".

Inserted before the last sentence as follows:

"If a remote
   address becomes unreachable, the traffic is switched over to a
   reachable one, if one exists.  [I-D.ietf-tsvwg-sctp-failover] specifies
a quicker failover operation
reducing he latency of the failover.
   Each SCTP end-point supervises
   continuously the reachability of all peer addresses using a heartbeat
   mechanism."

Section 3.3.2:

First bullet:

"In case of send failures that application .. " --> propose to replace
with

"In case of send failures, including drop of messages sent unreliably, the
application "

Third last paragraph:

snet --> sent

Section 3.3.3.

Suggest to replace:

fully reliable or partially reliable delivery --> with -->

fully reliable, partially reliable and unreliable delivery

Section 4.1:

I wonder if SCTP Reliability could be Full/Partial/None

I wonder if unordered delivery should be added as a row.

I am not sure if ECN for SCTP should be marked as TBD. Applicability of
RFC3168 to SCTP is described in RFC4960.
I personally don’t know of any deployment of this.


BR, Karen



> -----Original Message-----
> From: Taps [mailto:[e-mail]] On Behalf Of internet-
> [e-mail]
> Sent: 7. oktober 2015 12:43
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Taps] I-D Action: draft-ietf-taps-transports-07.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-07.txt
> 	Pages           : 53
> 	Date            : 2015-10-07
>
> 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:
> https://tools.ietf.org/html/draft-ietf-taps-transports-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-07
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps