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

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

BTW,

My personal opinion is that this document, in this version, is very good
and serves well the purpose of providing a
comprehensive survey of the services provided with a number of the IETF
transport protocols.

I do note, however, that the title of the document puts bigger emphasis on
congestion control than the document
content as such.

I further, personally, consider the document draft-welzl-taps-transport as
a good, and necessary, supplement
going more into the details of the existing transport service
interface(s).

Thanks.

BR, Karen

> -----Original Message-----
> From: Karen Elisabeth Egede Nielsen [mailto:[e-mail]]
> Sent: 28. oktober 2015 13:16
> To: '[e-mail]'.org'; 'Brian Trammell'; 'Mirja Kühlewind'; Michael Tuexen
> ([e-mail])
> Subject: RE: [Taps] I-D Action: draft-ietf-taps-transports-07.txt
>
> 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