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

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

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:[e-mail]]
> Sent: 27. oktober 2015 15:07
> To: Karen Elisabeth Egede Nielsen
> Cc: [e-mail]
> 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
> <[e-mail]> 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:[e-mail]] 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: <[e-mail]>
> >>> Subject: New Version Notification for
> >>> draft-welzl-taps-transports-00.txt
> >>> Date: 21 Sep 2015 10:35:33 CEST
> >>> To: Michael Welzl <[e-mail]>, Michael Welzl
> >>> <[e-mail]>, Michael Tuexen <[e-mail]>,
> >> Naeem
> >>> Khademi <[e-mail]>, Michael Tuexen <tuexen@fh-
> >> muenster.de>,
> >>> Naeem Khademi <[e-mail]>
> >>> Resent-From: <[e-mail]>
> >>>
> >>>
> >>> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/taps