Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 16 Jul 2015 11:22:52 +0200

HI,

A few initial comments the definition of the transport service features as
they appear from section 3 (and TAPS1):

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.

   o  non-reliable delivery:
       add SCTP

   o  reliable delivery:
        add SCTP

  Suggest to rephrase

   o  reliable and partially reliable delivery
-->
   o  partially reliable delivery:
      SCTP

   o  drop notification :
       add SCTP

   o  ordered delivery:
       add SCTP

   o  unordered delivery:
       add SCTP

Ideally, I think, then one would use a common term for Nagle(-like)
bundling for TCP and SCTP.

BR, Karen

>-----Original Message-----
>From: Taps [mailto:[email-masked]] On Behalf Of Michael Welzl
>Sent: Friday, June 26, 2015 9:22 AM
>To: taps WG
>Cc: Stein Gjessing
>Subject: [Taps] Fwd: New Version Notification for
draft-gjessing-taps-minset-
>00.txt
>
>Dear all,
>
>This is a very first stab at a draft addressing the charter's second item
- the
>minimal set of transport services that end systems should support.
>
>It is based on version 4 of draft-ietf-taps-transports, so the list of
features /
>components is not up to date - but that's not really the main point of
the
>document for now anyway:
>it's about showing how the number of exposed services *could* be reduced.
>Our hope is that, by sketching the possible destination of our journey,
this
>helps the current discussion of the first document.
>
>Cheers,
>Michael
>
>
>
>> Begin forwarded message:
>>
>> From: <[email-masked]>
>> Subject: New Version Notification for
>> draft-gjessing-taps-minset-00.txt
>> Date: 22 Jun 2015 14:37:43 CEST
>> To: Michael Welzl <[email-masked]>, Stein Gjessing
>> <[email-masked]>, Stein Gjessing <[email-masked]>, Michael Welzl
>> <[email-masked]>
>> Resent-From: <[email-masked]>
>>
>>
>> A new version of I-D, draft-gjessing-taps-minset-00.txt has been
>> successfully submitted by Michael Welzl and posted to the IETF
>> repository.
>>
>> Name:		draft-gjessing-taps-minset
>> Revision:	00
>> Title:		A Minimal Set of Transport Services for TAPS
Systems
>> Document date:	2015-06-22
>> Group:		Individual Submission
>> Pages:		10
>> URL:
https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-
>00.txt
>> Status:
https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
>> Htmlized:
https://tools.ietf.org/html/draft-gjessing-taps-minset-00
>>
>>
>> Abstract:
>>   This draft will eventually recommend a minimal set of IETF Transport
>>   Services offered by end systems supporting TAPS, and give guidance on
>>   choosing among the available mechanisms and protocols.  As a starting
>>   point for discussion, it currently only gives an overview of some
>>   ways to categorize the set of transport services in the first TAPS
>>   document (version 4: draft-ietf-taps-transports-04), assuming that
>>   the eventual minimal set of transport services will be based on a
>>   similar form of categorization.
>>
>>
>>
>>
>> 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-masked]
>https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Thu, 16 Jul 2015 13:23:17 +0200

Hi, thanks!

Below:

> On 16 Jul 2015, at 11:22, Karen Elisabeth Egede Nielsen <[email-masked]> wrote:
> 
> HI,
> 

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  partially reliable delivery:

ACK, thanks

> bundling for TCP and SCTP.

Agreed, we actually did that in Michael Welzl, Stefan Jörer, 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

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 16 Jul 2015 13:33:13 +0200

HI,

>From: Michael Welzl [mailto:[email-masked]]
>Sent: Thursday, July 16, 2015 1:23 PM
>To: Karen Elisabeth Egede Nielsen
>Cc: [email-masked]; Stein Gjessing
>Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt
>
>Hi, thanks!
>
>Below:
>
>
>> A few initial comments the definition of the transport service
>> features as they appear from section 3 (and TAPS1):
>>
>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).
>
[Karen ] Thanks. very precise. So we should call this single-sided or alike.
Not something that seems to have a direction or be related to how data
flows.
>Agreed, we actually did that in Michael Welzl, Stefan Jörer, 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,
[Karen ] Great.
>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.
>
[Karen ] Yes I understand that. But the write-up serves very well to help
unify and clarify the terms - which I suppose is the goal :-).

BR, Karen

---

From: Brian Trammell <[email-masked]>
Date: Thu, 16 Jul 2015 15:04:36 +0200

hi Michael,

...inline...

> On 16 Jul 2015, at 13:23, Michael Welzl <[email-masked]> wrote:

<snip>

> 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.

hm, so perhaps we should have coordinated here. That list, in that version, wasn't quite complete. In the current version it's still not quite complete, as we're still trying to nail down how to partition the space of features (and how to divide things that are actually features from things that are just accidental effects of the way protocols have evolved). There are also aspects of the interfaces (coming from the interface discussion) we'd like to capture, on which we'd like to discuss f2f next Thursday.

Perhaps another way to approach this would be to start with a list of features we think we want in doc 2, and to use the background from doc 1 to fill in the gaps...

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Fri, 17 Jul 2015 16:33:32 +0200

> On 16. jul. 2015, at 15.04, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 
> ...inline...
> 
> hm, so perhaps we should have coordinated here. That list, in that version, wasn't quite complete.

That doesn't matter - the point of the doc was to introduce the possible categorization and fill the "functional / non-functional" part with some examples so it's more understandable. If this list of examples is complete really doesn't matter.

> In the current version it's still not quite complete, as we're still trying to nail down how to partition the space of features (and how to divide things that are actually features from things that are just accidental effects of the way protocols have evolved). There are also aspects of the interfaces (coming from the interface discussion) we'd like to capture, on which we'd like to discuss f2f next Thursday.

ACK, indeed...

> Perhaps another way to approach this would be to start with a list of features we think we want in doc 2, and to use the background from doc 1 to fill in the gaps...

Bad idea I think. It raises horrible memories of TAPS creation. See, I started this off by saying that we have to do it bottom-up, by beginning with what protocols can do, not what services apps could want. This has disadvantages and is a compromise but it comes from looking at a history of well above a decade of people proposing these kinds of things and nothing coming out of it. That's because there are so many degrees of freedom and it's practically impossible to end up agreeing on anything.

My take-away from TAPS creation was that people had to share this experience together with me: let's do it top-down - oh, really, we can't agree - and now we're back at what I started with: bottom up.

Please please please let's not do another round on this ride with doc 2!   :-)

Cheers,
Michael