Hi, Thanks.
If this was not clear, then I should emphasize that I think this document is an excellent starting point ! BR, Karen > -----Original Message----- > From: Michael Welzl [mailto:[email protected]] > Sent: 27. oktober 2015 15:07 > To: Karen Elisabeth Egede Nielsen > Cc: [email protected] > Subject: 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 > <[email protected]> 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:[email protected]] 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: <[email protected]> > >>> Subject: New Version Notification for > >>> draft-welzl-taps-transports-00.txt > >>> Date: 21 Sep 2015 10:35:33 CEST > >>> To: Michael Welzl <[email protected]>, Michael Welzl > >>> <[email protected]>, Michael Tuexen <[email protected]>, > >> Naeem > >>> Khademi <[email protected]>, Michael Tuexen <tuexen@fh- > >> muenster.de>, > >>> Naeem Khademi <[email protected]> > >>> Resent-From: <[email protected]> > >>> > >>> > >>> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
