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

Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Wed, 28 October 2015 08:34 UTC

Return-Path: <karen.nielsen@tieto.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8681B3658 for <taps@ietfa.amsl.com>; Wed, 28 Oct 2015 01:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GDODFksmpnZ for <taps@ietfa.amsl.com>; Wed, 28 Oct 2015 01:34:38 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840921B3656 for <taps@ietf.org>; Wed, 28 Oct 2015 01:34:38 -0700 (PDT)
Received: by igdg1 with SMTP id g1so101684233igd.1 for <taps@ietf.org>; Wed, 28 Oct 2015 01:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=YT3vsRp1rXhjMMkuAaH8G4mka1rfqZUT6razsAJNXL0=; b=t5WmxmrTO1SRL8lE0mcincZmRwpIZwiUZcaEA65BxaRyHDkr3hpJ2BNBx3iVPI9hO4 uT37RikjKUzjmHjZMj5pOgzpeFWbfA1IZVJ00DKjmBie7qZBOoJb27r55/0bH0QF+XYv JxR2ci0EnKZ+IuIOFKFGngrWN28T7P9rJzgcw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=YT3vsRp1rXhjMMkuAaH8G4mka1rfqZUT6razsAJNXL0=; b=au3xFRSkm7N66TkZlyiP2+/0de27J+mz+Iwb8gRlIIU5QergiaZYGW01NwIeQFc5YR a+W3vylS8leMEOBCLMiOWhOiFxFGVpP9MTtTgHVqfg+3WAmCxjGvvRcN51m4gK5EjgYR 8ZqgeTtPxjq2B7mDGEmLA009jmMvinq2N4iSsFFc9iGPSbmIfSZQjzX8wRL5BltHFGqU YX8WF1kafpfUFoelbEddjIJ7Hg93kmhws2UmH2TtfvidWxYX2r2II0SYjGodocuKarWa A+1LSPrMDpmla9YCJwR8Hh9f/jPRPVW4MNCSMuTXLv24sK73TnWDiEFCuuHgSvN/8NQ6 lCLQ==
X-Gm-Message-State: ALoCoQkkoWnW4Md6uJ+qvtUTwXWf87eD4VCb67wvx+UyV6W9iSfMOL3AXhkTwZXi2UQGBOgVlud7zcaz2y9JAot7j7pAEOX/a0O1WI5iSL/D3ZxDg8clGWs=
X-Received: by 10.50.20.74 with SMTP id l10mr1642185ige.2.1446021277918; Wed, 28 Oct 2015 01:34:37 -0700 (PDT)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <20150921083533.19273.62189.idtracker@ietfa.amsl.com> <C5DCD4E3-C795-4C21-AA17-D59CA7F02D17@ifi.uio.no> <9ac4441c10c70ae76c7bb75dc3613494@mail.gmail.com> <CDFB8D5D-BE74-4879-B65B-207A96F0F8C5@ifi.uio.no>
In-Reply-To: <CDFB8D5D-BE74-4879-B65B-207A96F0F8C5@ifi.uio.no>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKdK9Xuvg/e8qMO2/7tp8zJAaxQOQC0KKL7ApUxzZACUuj4nJy7fK5w
Date: Wed, 28 Oct 2015 09:34:36 +0100
Message-ID: <2599cdcec9a767ff3d40695faa645836@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-DomainID: tieto.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/gVCuQ1H_9iCKDRm0mYo0p-dbuwo>
Cc: taps@ietf.org
Subject: Re: [Taps] New Version Notification for draft-welzl-taps-transports-00.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2015 08:34:41 -0000

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:michawe@ifi.uio.no]
> Sent: 27. oktober 2015 15:07
> To: Karen Elisabeth Egede Nielsen
> Cc: taps@ietf.org
> 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
> <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>no>, Michael Welzl
> >>> <michawe@ifi.uio.no>no>, Michael Tuexen <tuexen@fh-muenster.de>de>,
> >> Naeem
> >>> Khademi <naeemk@ifi.uio.no>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