Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Wed, 04 November 2015 23:02 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 CC7C01B369B for <taps@ietfa.amsl.com>; Wed, 4 Nov 2015 15:02:10 -0800 (PST)
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 WYrExXcuqONz for <taps@ietfa.amsl.com>; Wed, 4 Nov 2015 15:02:09 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (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 6CCC21B36AD for <taps@ietf.org>; Wed, 4 Nov 2015 15:02:08 -0800 (PST)
Received: by ioc74 with SMTP id 74so5817932ioc.2 for <taps@ietf.org>; Wed, 04 Nov 2015 15:02:07 -0800 (PST)
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; bh=cD8y9oXxZVSSxVT4ffvwOuuSNTTlSh0F+GAPDsu2Tjw=; b=eN7fJiJiO+p9H9ayyMkurYn3TlO1W6LTan8w1Tle57j6P1msDhVHogLsbrRjDxwWRS Rps8WyUmBN2sqeHc2/ocPDQrTp1ouhceL1rZePiInLm8UghXSZyNz3322Gshxw5xWzJO nFPVwWmLAfY8AEbv/mNShAFH23uHSN3+3s2XY=
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; bh=cD8y9oXxZVSSxVT4ffvwOuuSNTTlSh0F+GAPDsu2Tjw=; b=eDuGu1AYU618ElMtyG72DpjG+GqL0H7u65ZI5CuOZ1exDMFzrrNs87zMXJZi+KwUhH B80uWEm+PK1mmfCKFP4RN6flBDf/Yc6N6HNcQAzbpITWC/AHNblxh1fFC8tCAK88B5rb fPcSGQWA9riWcURwzVuNs0pAiSriF9ifhu0f8kWwlpXNkCRKnStbVy1/Is3m94l2nM2Q +n6GswHUk0GIVymTJXN+jzWA5o439Nxw5gSPLdUkZuho9ZzZjL6920PdS66XAADrtthI P0KORMo9IRzyx0cvHCdesnHqC1PPeduaUEFqCOmipUktsYydqOEGKJwpAWogsjyKc9/o iooA==
X-Gm-Message-State: ALoCoQmcYLTF4rgfu4aaRfSh9ce7Oz1ow9NIRuL1Vzf/ES51Jo8GADLq3Xhvs6qQ+yhEMK2rh+KsaABU+VpftiCSU9DZoRKIQJ+7Fv2ED3iBmjWNKyjbatE=
X-Received: by 10.107.155.16 with SMTP id d16mr5703031ioe.38.1446678127593; Wed, 04 Nov 2015 15:02:07 -0800 (PST)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <945E755A-3EB4-4325-8257-9ECC2EE3FC4B@ifi.uio.no> <6f6d07994fde18062e39ced796f199a9.squirrel@erg.abdn.ac.uk> <168e06db09417654f64461f700a0d4f5@mail.gmail.com> <563A4A4E.4020904@isi.edu> <7249EAF7-C6C0-47AC-9B22-FF7DE41B8EC9@ifi.uio.no>
In-Reply-To: <7249EAF7-C6C0-47AC-9B22-FF7DE41B8EC9@ifi.uio.no>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLqPZ7YNAMdgKXUwCSqRxv62pP6+wJmZ4dkAhiQoQkBuvM/mAKAV7C8nBRYTcA=
Date: Thu, 05 Nov 2015 08:02:09 +0900
Message-ID: <29a27419ea3726f88aabf36edb50926c@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>, Joe Touch <touch@isi.edu>
Content-Type: text/plain; charset="UTF-8"
X-DomainID: tieto.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/hvGGApWhWj968RHMIp0-8gpAQBY>
Cc: gorry@erg.abdn.ac.uk, taps@ietf.org
Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
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, 04 Nov 2015 23:02:11 -0000

HI,

>
> I believe that was just a misunderstanding: Karen thought that I had
only
> used RFC793 when writing draft-welzl-taps-transports-00, but really I
did try
> to use all relevant RFCs.
>
[Karen Elisabeth Egede Nielsen] ......well, I did observe that you were
referring to rfc1122 (and also RFC6093).
but the result and the emphasis on the PUSH bit made me think that weight
only was put on what was written in RFC 793. ;-)

BTW,  something which I didn't mention yesterday, but now got the "energy"
to in and find is the following:

Send:  This sends a message of a certain length in bytes over an
      association.  A number can be provided to later refer to the
      correct message when reporting an error and a stream id is
      provided to specify the stream to be used inside an association
      (we consider this as a mandatory parameter here for simplicity: if
      not provided, the stream id defaults to 0).  An optional maximum
      life time can specify the time after which the message should be
      discarded rather than sent.  A choice (advisory, i.e. not
      guaranteed) of the preferred path can be made by providing a
      destination transport address, and the message can be delivered
      out-of-order if the unordered flag is set.  Another advisory flag
      indicates the ULP's preference to avoid bundling user data with
      other outbound DATA chunks (i.e., in the same packet).  The

^^^^
      handling of this no-bundle flags is similar to the sender side
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      handling of the TCP PUSH flag.
      ^^^^^^^^^^^^^^^^^^^^^^^^
      A payload protocol-id can be
      provided to pass a value that indicates the type of payload
      protocol data to the peer.

Can we agree to have this be removed also :-).
Bundling in SCTP is similar to Nagle. Indeed it is often implemented as
Nagle exactly
(though with add-ons). Comparing it to PUSH is NOT helpful.

Then, there is the additional discussion about RFC4960 and RFC6458 (socket
api) in that
bundling control is not often implemented as a flag on a message, but as
in TCP on a per association/connection level.
This again made me think emphasis was put on RFC793/RFC4960 and not much
else ;-).

BR, Karen

> Cheers,
> Michael