Re: [Taps] Fwd: New Version Notification for draft-welzl-taps-transports-00.txt

HI,

FWIIW please accept the following comments to the document:

Section 3.1:

"Passive open with fully specified foreign socket"

Is that a typical function provided to ULP by TCP ?
Our POSIX socket api implementation does not really provide this. Or it
does by set of special filters on the
listening socket, but I wasn't aware that this was a feature generally
available in TCP.

"Passive open with fully specified foreign socket" on a unspecified
passive open socket ?

I assume we speak listening socket. Again is this something typically
provided as an option to ULP by TCP ?

"Send: and PUSH flag description":

The PUSH flag is typically set inside the TCP implementation and the ULP
typically has no direct influence on the setting of it. I think that it is
strange that this function
is chosen to be described as if it is controlled directly by ULP when it
is indeed not.

There is some text later in section 3.1.1 motivating the choice. Yes it is
correct that TCP implementations implement
set of PUSH flag causing a behavior (i.e., a set of PUSH) that matches
that the PUSH flag is set in the end of a communication,
but again it is not controlled by ULP. As the intend of this document is
to expose services that the ULP
can invoke, I think that it is problematic that it is described as if the
ULP can control PUSH directly, when it indeed (often) cannot.

Section 3.2:

General comment:

The multi-stream capability and stream prioritization/scheduling
possibilities of SCTP is a feature
differentiating SCTP from TCP. The same is the fact that SCTP (SCTP-PR)
also provide unreliable (no retransmissions) and partial reliable
transport service (timeout).

I think that these service features are important for certain SCTP
deployment scenarios
and that it would be desirable for these to be exposed here. (The timeout
is described)
 It not included here in the first pass it will never even get considered
 for TAPS as a potential service, would it ?
 (It might end up being excluding, but then this should be a
conscious (visible) choice, I think).

Detailed comments:

"Initialize needs be called only once per set of local addresses":

This is the case when supporting one-to-many style sockets. Perhaps one
might add
"but ULP may also initialize each association endpoint instance
individually".

"Associate":

I think that it is relevant to clarify that the remote SCTP instance in
the association primitive is
identified by one or multiple destination addresses thus allowing also the
association handshake
to proceed using multiple paths.

"Send":

"Another advisory flag indicates the ULP's preference to avoid bundling
user data .."

This is specified as an optional attribute in RFC4960. This is not
specified in the RFC6458 socket API.
((Yes it might be similar to the TCP PUSH flag in that it is not generally
implemented as directly controllable by ULP on a message basis - Or?))

Section 4.2:

SCTP implements NO_delay (Nagle) option on a per association basis (as TCP
on a per connection basis) but not typically
on a per message basis as described here. There are some additional
bundling control related to stream scheduling - some are described in
sctp-ndata draft.

Section 5.1:

"Disable Nagle algorithm:"

Not specified in RFC4960, but in RFC6458 for SCTP.
Is it really valid to use RFC4960 as a reference for the socket API when
the approach of
SCTP IETF community has been to use RFC6458 for this ?

***

BR, Karen

> -----Original Message-----
> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Michael Welzl
> Sent: 21. september 2015 10:45
> To: taps WG
> Subject: [Taps] Fwd: New Version Notification for draft-welzl-taps-
> transports-00.txt
>
> Dear all,
>
> In my presentation in Prague, I proposed an approach to identify the
services
> that transport protocols provide. At the end of the ensuing discussion,
I said
> that I (with co-authors) would write a draft that explains the proposal
by
> applying the proposed method to TCP and SCTP.
>
> We just submitted this document - see below;  I hope that this will lead
to
> some discussion on the list...
>
> Cheers,
> Michael
>
>
> > Begin forwarded message:
> >
> > From: <internet-drafts@ietf.org>
> > Subject: New Version Notification for
> > draft-welzl-taps-transports-00.txt
> > Date: 21 Sep 2015 10:35:33 CEST
> > To: Michael Welzl <michawe@ifi.uio.no>, Michael Welzl
> > <michawe@ifi.uio.no>, Michael Tuexen <tuexen@fh-muenster.de>,
> Naeem
> > Khademi <naeemk@ifi.uio.no>, Michael Tuexen <tuexen@fh-
> muenster.de>,
> > Naeem Khademi <naeemk@ifi.uio.no>
> > Resent-From: <michawe@ifi.uio.no>
> >
> >
> > A new version of I-D, draft-welzl-taps-transports-00.txt
> > has been successfully submitted by Michael Welzl and posted to the
> > IETF repository.
> >
> > Name:		draft-welzl-taps-transports
> > Revision:	00
> > Title:		An Approach to Identify Services Provided by
> IETF Transport Protocols and Congestion Control Mechanisms
> > Document date:	2015-09-21
> > Group:		Individual Submission
> > Pages:		23
> > URL:            https://www.ietf.org/internet-drafts/draft-welzl-taps-
> transports-00.txt
> > Status:
https://datatracker.ietf.org/doc/draft-welzl-taps-transports/
> > Htmlized:
https://tools.ietf.org/html/draft-welzl-taps-transports-00
> >
> >
> > Abstract:
> >   This document describes a method to identify services in transport
> >   protocols and congestion control mechanisms.  It shows the approach
> >   using TCP and SCTP (base protocol) as examples.
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat
> >
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps