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

Karen Elisabeth Egede Nielsen <> Tue, 27 October 2015 13:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 272451A89B0 for <>; Tue, 27 Oct 2015 06:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l6RSIhk-gzkl for <>; Tue, 27 Oct 2015 06:58:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A69801A89A6 for <>; Tue, 27 Oct 2015 06:58:54 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so83030563igb.0 for <>; Tue, 27 Oct 2015 06:58:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type; bh=iuFPBUzHYMuHXuki8h0RPy25lTsvRyrpLjBqOOHxoro=; b=VIbQhl+qdZZ6M3uYi4lq0+WnXAGp+rZ95EfYJ1xeS+P6q/fpN6uLik8kbcPvt7OA3l Y7oaKgR8ptm/EtWTuVMqTV8v/oUlHxK3RgIsfITAPqT3UQXKhzu6WqFPDdN/Iw70gnz1 o4ELlSwqYj9z5MI9qPjdw5qiXbFg4KT2nISpk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=iuFPBUzHYMuHXuki8h0RPy25lTsvRyrpLjBqOOHxoro=; b=iLNpEefpYyZyT5BhHlrKlosa0bnfOvOnYyYQGQKcTSav1HvRYr3lyFU0kcrpu/L955 /Y4m/x2JgJpoIeUhdtd0kGEPbLWqrTYROYnbKN3pf7w2tAeKpW4ig99joNlS9KLfMYM7 FLeCeWGjJCBj676D5kAYUtmh9lx/lOCivIMTchaEqET4PLreZJcZRnCFNu0VGmRoojB9 K/UGfCg6EyW4EGzb3JP2bz59E5VSqYHHqaFQgnbhgW9OGDpBmOrUYxKSPSd7J9Fg9ZDw /AhJjSByVcgevh1mq/rkZqruiLsVAIlFUG3Qf/PF3n22JxrW587r+h1HlnMWwPXjpI60 MC/Q==
X-Gm-Message-State: ALoCoQle0p2jXvajrIOIKfpt+5gjEtZquDJTTBdT8FHhTQiN2Nce/mpHCpJQWRfVxmR+Hkn0F3Ac63idNuayu+urd2tbWZ39nKjXbKH0WlaDQln9+HjxtJA=
X-Received: by with SMTP id v5mr25685758igz.2.1445954334013; Tue, 27 Oct 2015 06:58:54 -0700 (PDT)
From: Karen Elisabeth Egede Nielsen <>
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
thread-index: AQKdK9Xuvg/e8qMO2/7tp8zJAaxQOQC0KKL7nOF2XUA=
Date: Tue, 27 Oct 2015 14:58:52 +0100
Message-ID: <>
To: Michael Welzl <>, taps WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Taps] Fwd: New Version Notification for draft-welzl-taps-transports-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Oct 2015 13:58:57 -0000


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


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.


"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 [] 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
> 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
> applying the proposed method to TCP and SCTP.
> We just submitted this document - see below;  I hope that this will lead
> some discussion on the list...
> Cheers,
> Michael
> > Begin forwarded message:
> >
> > From: <>
> > Subject: New Version Notification for
> > draft-welzl-taps-transports-00.txt
> > Date: 21 Sep 2015 10:35:33 CEST
> > To: Michael Welzl <>, Michael Welzl
> > <>, Michael Tuexen <>,
> Naeem
> > Khademi <>, Michael Tuexen <tuexen@fh-
> > Naeem Khademi <>
> > Resent-From: <>
> >
> >
> > 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:  
> transports-00.txt
> > Status:
> > Htmlized:
> >
> >
> > 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
> >
> > The IETF Secretariat
> >
> _______________________________________________
> Taps mailing list