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

Dear Karen,

Thanks a lot for your comments!
This was only meant as a starting point - e.g. the decision to only use RFC4960 but not RFC6458 is definitely not set in stone.

We’ll incorporate them in the next revision (and then maybe get back to you in case we need discussion) - thanks again!

Cheers,
Michael

> On 27. okt. 2015, at 14.58, Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> wrote:
> 
> 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