Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com>
Date: Thu, 16 Jul 2015 13:23:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6A77B18-C8F4-4C87-8493-8FF11AC98AA1@ifi.uio.no>
References: <5b2e19f286a3eaf18d2ccf7da39abbbf@mail.gmail.com>
To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/ErUpsEqv6dybaTqlZ_Ke7I_G3c0>
Cc: Stein Gjessing <steing@ifi.uio.no>, "taps@ietf.org" <taps@ietf.org>
Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt
Precedence: list

Hi, thanks!

Below:


> On 16 Jul 2015, at 11:22, Karen Elisabeth Egede Nielsen =
<karen.nielsen@tieto.com> wrote:
>=20
> HI,
>=20
> A few initial comments the definition of the transport service =
features as
> they appear from section 3 (and TAPS1):
>=20
> Unidirectional/bidirectional: I am not sure what this means exactly:
> Does it refer to that data transfer is negotiated for both directions
> perhaps ? But then it only applies to connection oriented transport.
> Does it refer to that control info is going back ?
> Does it refer to that messages (which ever form) are going back on the
> reverse network path ? Then it does not necessarily apply to SCTP MH.

Sorry for not being clear enough: it means that it's a feature that can =
be used just on one side, without requiring the other side to be =
involved  (e.g. Nagle is just a sender-side mechanism).


>   o  non-reliable delivery:
>       add SCTP
>=20
>   o  reliable delivery:
>        add SCTP
>=20
>  Suggest to rephrase
>=20
>   o  reliable and partially reliable delivery
> -->
>   o  partially reliable delivery:
>      SCTP
>=20
>   o  drop notification :
>       add SCTP
>=20
>   o  ordered delivery:
>       add SCTP
>=20
>   o  unordered delivery:
>       add SCTP

ACK, thanks


> Ideally, I think, then one would use a common term for Nagle(-like)
> bundling for TCP and SCTP.

Agreed, we actually did that in Michael Welzl, Stefan J=C3=B6rer, Stein =
Gjessing: "Towards a Protocol-Independent Internet Transport API", =
FutureNet IV workshop in conjunction with of IEEE ICC 2011, 5-9 June =
2011, Kyoto, Japan,
using app PDU bundling because it's more meaningful than Nagle.

But here the idea was just to copy+paste the list from doc 1 (version 4) =
and put things under the correct headings, as a way to show how we =
*could* apply categorization methods.

Cheers,
Michael