Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 1 Jul 2014 07:39:20 -0500

Lloyd,

I tend to use more slang than most, but almost always include a link to a
definition when I'm aware of it. This time, I didn't.

I apologize to those who were confused, inconvenienced by working to not be
confused, or both.

Spencer

On Sunday, June 29, 2014, [email-masked] <[email-masked]> wrote:

>  I had to look up bikeshed and bikeshedding.
>
> Wasn't there a recent RFC on not using slang?
> ------------------------------
> *From:* Michael Welzl <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Sent:* Sunday, 29 June 2014 7:42:17 PM
> *To:* Aaron Falk
> *Cc:* Wood L Dr (Electronic Eng); Marie-Jose Montpetit; Spencer Dawkins; <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>;
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>; <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Subject:* Re: [Taps] Charter bikeshed #1 - "transport service"
>
>  If noone reacts by tomorrow, I'd suggest to assume the list's charter
> discussion has converged with Anna's last message.
>
>  I didn't want to kill off this discussion, however. I'll answer Aaron's
> email but with a different subject  :-)
>
>  Cheers,
> Michael
>
>
>  On 28. juni 2014, at 19:12, Michael Welzl <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>  one thing matters here, now: this is not about charter text, right?
>
> Sent from my iPhone
>
> On 28. juni 2014, at 16:46, Aaron Falk <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>  Sounds like there are two points here worth teasing apart:
>
>  1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT that
> is delivered" are different
>
>  and
>
>  2. Each is a 'dimension' rather than a binary characteristic (like, say,
> in order delivery)
>
>  --aaron
>
>
> On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>  I would say that we should not limit it to one or the other but make it
>> dependent on the application requirement.
>>
>> Marie-José Montpetit
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> On Jun 28, 2014, at 5:31, <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>  on reliability, are we talking of reliable erasure-free DELIVERY or
>> reliable error-free CONTENT that is delivered?
>>
>> Two dimensions here. We spent a few years debating the nuances in DTNRG.
>>
>> e.g. TCP is thought to offer both, but its payload content check is weak.
>> SCTP can vary delivery reliability, while its payload check is stronger.
>> UDP-Lite doesn't give reliable delivery, its content check can vary, etc.
>> ------------------------------
>> *From:* Taps <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of
>> Anna Brunstrom <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> *Sent:* Saturday, 28 June 2014 1:07:41 AM
>> *To:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> *Cc:* [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>;
>> [email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> *Subject:* Re: [Taps] Charter bikeshed #1 - "transport service"
>>
>>  Hi,
>>
>> Repeating one of my comments on the long mail to this more manageable
>> version that Micheal produced while I was reading.
>>
>> Anna
>>
>> On 2014-06-27 16:38, Michael Welzl wrote:
>>
>> Hi,
>>
>>  I'll cut away a lot now, and only address things that need addressing
>> below:
>>
>>
>>   On 27. juni 2014, at 16:21, Toby Moncaster <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>  [snip]
>>
>>   I agree with Michael here. I think we could end up with a much less
>> clearly worded charter if we go down that route. If there is a need to be
>> more precise then I’d favour adding something near the beginning of the
>> charter along the lines of the definition I put in the Problem Statement
>> document. Namely:  "A Transport Service is any service provided by the
>> transport layer that can only be correctly implemented with information
>> from the application.”We could then include 2 or 3 example services
>>
>>
>>  I agree. Putting that definition in there would be nice.
>>
>>
>>          - full reliability
>>
>>       - latency-limited reliability
>>
>>
>>   Yes, reliability is a service, and fine to include in the list. But
>> I'd rather replace this with any of:
>> "various degrees of reliability" or "various forms of reliability" or
>> "full / latency-limited / no reliability"
>> ...or something like that.  One item, not two, anyway.
>>
>>
>>
>>  Hmmm. I’d rather we had something like “Degree of reliability from
>> unreliable to full reliability."
>>
>>
>>  Agree.
>>
>>
>>      Second, using the phrase "congestion control" binds the application
>> requirement to a specific mechanism. I'd rather use something like "low
>> delay vs. high throughput”.
>>
>>
>>  Perhaps this would best be expressed as “Trading off latency and
>> throughput"
>>
>>
>>  Agree.
>>
>>
>>     I don't know if this list is correct or complete. This should be the
>> WG
>> job to compile it.
>> Btw, adding this list to the charter, as a starting point, would make
>> sense.
>>
>>
>>  So, to summarize, here's the complete list that I suggest:
>>
>>  - sequence preservation
>> - various degrees of reliability
>> - low delay vs. high throughput
>>
>>
>>  I’d rephrase this as:
>>
>>  - ordering/sequence preservation
>> - degree of reliability
>> - latency vs throughput
>>
>>
>>  Agree, this is nicer!
>>
>>
>>      How do we call the transport that support those 5 things? a
>> transport
>> protocol? a transport service?
>> The "services" term is used multiple times within the charter.
>> Sometimes I understand it as a "transport protocol" (like in the first
>> sentence in the charter),
>> And sometimes I may interpret it as Brian's "dimensions of transport" or
>> criteria.
>>
>> Potentially use "criteria" and "transport protocol"
>> Alternatively, only use "transport services" when it means "criteria, and
>> "transport protocol".
>> I tried to do the latter below.
>>
>>
>>
>>  Again, detailed comments in line:
>>
>>
>>  OLD:
>>
>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>> UDP-Lite and the LEDBAT congestion control mechanism extend
>> the set of transport services that are available to
>> applications, beyond those provided by TCP and UDP. For
>> example, SCTP provides potentially faster reliable delivery
>> for applications that can accept blocks of data out of order,
>> and LEDBAT provides low-priority "scavenger" communication.
>>
>> NEW:
>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>> UDP-Lite and the LEDBAT congestion control mechanism extend
>> the set of transport protocols that are available to
>> applications, beyond those provided by TCP and UDP. For
>> example, SCTP provides potentially faster reliable delivery
>> for applications that can accept blocks of data out of order,
>> and LEDBAT provides low-priority "scavenger" communication.
>>
>>
>>  Disagree, I'd rather leave it as it is to stress that applications use
>> services, not protocols.
>>
>>
>>
>>  I actually think changing that to protocols might be a good thing,
>> since it highlights how complex the landscape has become.
>>
>>
>>
>> I disagree. The "For example" list gets very strange as examples of
>> transport protocols. I also agree with Michael's original objection:
>> stressing that applications use services is important.
>>
>>
>>
>>   Okay, fine by me. I don't have a strong opinion here either way.
>>
>>
>>
>>     OLD:
>>
>> - Identify services provided by existing IETF transport protocols
>>   and congestion control mechanisms. The resulting document will
>>   provide guidance on making a choice among available mechanisms
>>   and protocols to obtain a certain transport service.
>>
>>
>> NEW:
>>
>> - Identify transport services provided by existing IETF transport
>> protocols
>>   and congestion control mechanisms. The resulting document will
>>   provide guidance on making a choice among available mechanisms
>>   and protocols to obtain a certain transport service. As a starting
>> point
>>   for transport services, the working group can consider: message
>> atomicity,
>>   stream fragmentation, sequence preservation, head-of-line blocking
>> avoidance,
>>   sub-channels, full reliability, latency-limited reliability,
>> loss-sensitive
>>   congestion control, delay-sensitive congestion control, endpoint
>> address agility,
>>   privacy and integrity, and path-state propagation (NAT/Firewall).
>>
>>
>>  Sentence 1: "transport services provided by ..  transport protocols"
>> doesn't seem to make things clearer. I'd rather keep "services" in this
>> sentence - what this means gets concrete anyway due to the list that
>> follows in sentence 3, and there the phrase "transport services" is used
>> anyway. The list should be changed, as I argued above. I suggest:
>>
>>  NEW:
>>
>>  - Identify services provided by existing IETF transport protocols
>>   and congestion control mechanisms. The resulting document will
>>   provide guidance on making a choice among available mechanisms
>>   and protocols to obtain a certain transport service. As a starting point
>>   for transport services, the working group can consider: sequence
>>   preservation, various degrees of reliability, low delay vs. high
>> throughput.
>>
>>
>>  I think here we’re once again running into the difficulty of the
>> ambiguity of the word “transport”, especially in the IETF… If we have
>> defined Transport Services in terms of the transport protocol earlier in
>> the document, can we actually phrase this
>>
>>  - Identify Transport Services provided by IETF protocols and congestion
>> control mechanisms
>>
>>
>>  Agreed
>>
>>
>>     OLD:
>> - Specify experimental mechanisms to deliver a transport service.
>>   This will explain how to select and engage a protocol, and how
>>   to discover the availability of protocols on an interface (both
>>   end system and path support), in order to provide a basis for
>>   incremental deployment.
>>
>> NEW:
>> - Specify experimental mechanisms to deliver a transport protocol.
>>   This will explain how to select and engage a protocol, and how
>>   to discover the availability of protocol services on an interface (both
>>
>>   end system and path support), in order to provide a basis for
>>   incremental deployment.
>>
>>
>>
>>  Disagree. "deliver a transport protocol" is weird. The intention was to
>> say "provide a transport service", maybe "deliver" is a bad choice of words
>> here? So I suggest:
>>
>>  NEW:
>> - Specify experimental mechanisms to provide a transport service.
>>   This will explain how to select and engage a protocol, and how
>>   to discover the availability of protocols on an interface (both
>>   end system and path support), in order to provide a basis for
>>   incremental deployment.
>>
>>
>>  Specify experimental mechanisms to provide a given Transport Service.
>> This will explain how to select and engage an appropriate protocol and
>> how to discover which protocols are available for a given connection.
>> This will provide a basis for incremental deployment.
>>
>>
>>  Agreed.
>>
>>
>>      "The Working Group will coordinate closely with other Working
>> Groups and
>> IRTF Research Groups."
>> You should list the WGs you have in mind.
>>
>>
>>  I agree that it looks odd as it stands. I'm not sure what the right
>> approach is here (simply remove? or what are these groups?) - e.g. Spencer
>> would know better than me…
>>
>>
>>
>>  I think the key thing here was that we aren’t only limiting ourselves
>> to working with the IETF but are also interested in getting input from the
>> IRTF. However I think we can drop this
>>
>>
>>  Agreed.
>>
>>  Cheers,
>> Michael
>>
>>
>>
>> _______________________________________________
>> Taps mailing [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>https://www.ietf.org/mailman/listinfo/taps
>>
>>
>>  _______________________________________________
>> Taps mailing list
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> https://www.ietf.org/mailman/listinfo/taps
>>
>>
>> _______________________________________________
>> Taps mailing list
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> https://www.ietf.org/mailman/listinfo/taps
>>
>>
>  _______________________________________________
> Taps mailing list
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> https://www.ietf.org/mailman/listinfo/taps
>
>  _______________________________________________
> Taps mailing list
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> https://www.ietf.org/mailman/listinfo/taps
>
>
>

---

From: <[email-masked]>
Date: Tue, 1 Jul 2014 14:43:03 +0000

http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
includes an explanation.
________________________________
From: Spencer Dawkins at IETF <[email-masked]>
Sent: Tuesday, 1 July 2014 10:39:20 PM
To: Wood L Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

Lloyd,

I tend to use more slang than most, but almost always include a link to a definition when I'm aware of it. This time, I didn't.

I apologize to those who were confused, inconvenienced by working to not be confused, or both.

Spencer

On Sunday, June 29, 2014, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:
I had to look up bikeshed and bikeshedding.

Wasn't there a recent RFC on not using slang?
________________________________
From: Michael Welzl <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Sent: Sunday, 29 June 2014 7:42:17 PM
To: Aaron Falk
Cc: Wood L Dr (Electronic Eng); Marie-Jose Montpetit; Spencer Dawkins; <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>; <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

If noone reacts by tomorrow, I'd suggest to assume the list's charter discussion has converged with Anna's last message.

I didn't want to kill off this discussion, however. I'll answer Aaron's email but with a different subject  :-)

Cheers,
Michael

On 28. juni 2014, at 19:12, Michael Welzl <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

Sent from my iPhone

On 28. juni 2014, at 16:46, Aaron Falk <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT that is delivered" are different

and

2. Each is a 'dimension' rather than a binary characteristic (like, say, in order delivery)

--aaron

On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
I would say that we should not limit it to one or the other but make it dependent on the application requirement.

Marie-José Montpetit
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>

On Jun 28, 2014, at 5:31, <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

on reliability, are we talking of reliable erasure-free DELIVERY or reliable error-free CONTENT that is delivered?

e.g. TCP is thought to offer both, but its payload content check is weak. SCTP can vary delivery reliability, while its payload check is stronger. UDP-Lite doesn't give reliable delivery, its content check can vary, etc.
________________________________
From: Taps <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of Anna Brunstrom <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Sent: Saturday, 28 June 2014 1:07:41 AM
To: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Cc: [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

Hi,

Repeating one of my comments on the long mail to this more manageable version that Micheal produced while I was reading.

Anna

I'll cut away a lot now, and only address things that need addressing below:

On 27. juni 2014, at 16:21, Toby Moncaster <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:

[snip]

I agree with Michael here. I think we could end up with a much less clearly worded charter if we go down that route. If there is a need to be more precise then I’d favour adding something near the beginning of the charter along the lines of the definition I put in the Problem Statement document. Namely:  "A Transport Service is any service provided by the transport layer that can only be correctly implemented with information from the application.”We could then include 2 or 3 example services

    - full reliability

Yes, reliability is a service, and fine to include in the list. But I'd rather replace this with any of:
"various degrees of reliability" or "various forms of reliability" or "full / latency-limited / no reliability"
...or something like that.  One item, not two, anyway.

Hmmm. I’d rather we had something like “Degree of reliability from unreliable to full reliability."

Agree.

Second, using the phrase "congestion control" binds the application requirement to a specific mechanism. I'd rather use something like "low delay vs. high throughput”.

Perhaps this would best be expressed as “Trading off latency and throughput"

Agree.

I don't know if this list is correct or complete. This should be the WG
job to compile it.
Btw, adding this list to the charter, as a starting point, would make
sense.

- sequence preservation

I’d rephrase this as:

Agree, this is nicer!

How do we call the transport that support those 5 things? a transport

OLD:

NEW:

Disagree, I'd rather leave it as it is to stress that applications use services, not protocols.

I actually think changing that to protocols might be a good thing, since it highlights how complex the landscape has become.

I disagree. The "For example" list gets very strange as examples of transport protocols. I also agree with Michael's original objection: stressing that applications use services is important.

OLD:

NEW:

Sentence 1: "transport services provided by ..  transport protocols" doesn't seem to make things clearer. I'd rather keep "services" in this sentence - what this means gets concrete anyway due to the list that follows in sentence 3, and there the phrase "transport services" is used anyway. The list should be changed, as I argued above. I suggest:

NEW:

  preservation, various degrees of reliability, low delay vs. high throughput.

I think here we’re once again running into the difficulty of the ambiguity of the word “transport”, especially in the IETF… If we have defined Transport Services in terms of the transport protocol earlier in the document, can we actually phrase this

- Identify Transport Services provided by IETF protocols and congestion control mechanisms

Agreed

OLD:

NEW:

Disagree. "deliver a transport protocol" is weird. The intention was to say "provide a transport service", maybe "deliver" is a bad choice of words here? So I suggest:

NEW:

Agreed.

 "The Working Group will coordinate closely with other Working Groups and
IRTF Research Groups."
You should list the WGs you have in mind.

I agree that it looks odd as it stands. I'm not sure what the right approach is here (simply remove? or what are these groups?) - e.g. Spencer would know better than me…

I think the key thing here was that we aren’t only limiting ourselves to working with the IETF but are also interested in getting input from the IRTF. However I think we can drop this

Agreed.

Cheers,
Michael

_______________________________________________
Taps mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Jun 2014 15:20:40 -0700

On Jun 30, 2014, at 2:53 PM, Michael Welzl <[email-masked]> wrote:

> 
> On 30. juni 2014, at 19:03, Joe Hildebrand (jhildebr) <[email-masked]> wrote:
> 
>> On 6/27/14, 8:45 AM, "Michael Welzl" <[email-masked]> wrote:
>> 
>>> Can we try to make a simple decision here, as a group, to never even
>>> really consider streams at all?
>>> 
>>> 
>>> It seems to me to be straightforward to provide a stream-based transport
>>> over a message-based transport, so this is something that can simply
>>> always be done. Thus, can we just write a disclaimer in one of our
>>> documents, recommending that any TAPS-supporting
>>> systems can provide stream-based transport on top of the message based
>>> transport too, but that its users must be aware of limitations that arise
>>> from streams (such as HOL blocking delay, no ALF, ..)?
>> 
>> Maybe, if we also have:
>> 
>> - retransmission
>> - order preservation
>> - optional nagle-ish grouping
>> - optional FEC
>> - whatever else I'm missing
>> 
>> At which point it might be straightforward to build a stream, but we still
>> might want to suggest how to combine the characteristics together into a
>> larger bit of functionality.
> 
> Sure; you can do all these things with messages, but it's harder or in some cases impossible with streams. You can turn much into a stream but not vice versa. Case in point: Minion - by merely introducing a marker in the byte stream that separates messages, all kinds of good things become possible.

Messages can be turned into streams and streams can be turned into messages, but there's an efficiency cost when the application data model doesn't match the network data model.

However, there's a lot more to life than just messages or streams, i.e., that's only 2 of many alternatives.

Joe

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 10 Jul 2014 13:43:17 -0500

On 06/25/2014 08:15 AM, Benoit Claise wrote:
> Benoit Claise has entered the following ballot position for
> charter-ietf-taps-00-00: Block

I've worked through feedback from internal review with the TAPS mailing 
list folk, and provided an update at 
http://datatracker.ietf.org/doc/charter-ietf-taps/ (for the IESG, that's 
"the usual place").

Benoit had the only block on 00-00, but other ADs may want to look it 
over as well.

It's substantially improved, thanks to comments from both the IESG and 
IAB, I think. Thank you all.

I'd like to get this approved for community review before the TAPS BOF 
at IETF 90, so that the community will have an opportunity to provide 
feedback during the meeting week. If anyone sees problems that would get 
in the way, please let me know.

Spencer

> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/charter-ietf-taps/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> I support the work, but I have a BLOCK anyway. The charter needs to
> clarify a few points.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 11 Jul 2014 14:53:03 +0000

This discussion is as old as TCP. One can build a message interface on a stream interface (RFCs 1006 and 2126) and a stream interface on a packet interface. When I want to send a large message, such as a file, the difference between the two is difficult to discern: either way one slices that cookie, one has a lot of transport PDUs being sent; the only real difference is at the receiving end, which might want to receive the stream as it arrives or the message when it has completely arrived.

IMHO, the API will do well to let the client advise it regarding what type of interface it wants, and go with it.

On Jun 27, 2014, at 7:45 AM, Michael Welzl <[email-masked]> wrote:

> Hi,
> 
> I changed the subject because this is not about the chartering discussion anymore - it's beginning our work   :-)
> 
> 
> Toby, in his last email, raised the following question:
> 
> On 27. juni 2014, at 16:21, Toby Moncaster <[email-masked]> wrote:
> 
> [snip]
> 
> 
>>>>>>     - message atomicity
>>>> 
>>>> What's that? That multiple messages are not combined into one packet? This plays a role for an application only when there is significant loss (I think). Wouldn't it be nice to have a system that provides atomicity only when needed and otherwise saves header overhead? I would vote against exposing that. Either way, I vote it off the list that goes in the charter, it's not an obvious service to me.
>> 
>> To some extent I agree here. But is there any way we can correctly express the differences between stream and packet oriented transports?
> 
> Can we try to make a simple decision here, as a group, to never even really consider streams at all?
> 
> It seems to me to be straightforward to provide a stream-based transport over a message-based transport, so this is something that can simply always be done. Thus, can we just write a disclaimer in one of our documents, recommending that any TAPS-supporting systems can provide stream-based transport on top of the message based transport too, but that its users must be aware of limitations that arise from streams (such as HOL blocking delay, no ALF, ..)?
> 
> Cheers,
> Michael
> 
> [email-masked]

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 11 Jul 2014 17:14:54 +0100

yep  - prob best work on this to date is bryan ford's structured streams
stuff (in sigcomm 2007)
http://www.brynosaurus.com/pub/net/sst-abs.html

On Fri, Jul 11, 2014 at 3:53 PM, Fred Baker (fred) <[email-masked]> wrote:

> This discussion is as old as TCP. One can build a message interface on a
> stream interface (RFCs 1006 and 2126) and a stream interface on a packet
> interface. When I want to send a large message, such as a file, the
> difference between the two is difficult to discern: either way one slices
> that cookie, one has a lot of transport PDUs being sent; the only real
> difference is at the receiving end, which might want to receive the stream
> as it arrives or the message when it has completely arrived.
>
> What's that? That multiple messages are not combined into one packet? This
> plays a role for an application only when there is significant loss (I
> think). Wouldn't it be nice to have a system that provides atomicity only
> when needed and otherwise saves header overhead? I would vote against
> exposing that. Either way, I vote it off the list that goes in the charter,
> it's not an obvious service to me.
>
>
> To some extent I agree here. But is there any way we can correctly express
> the differences between stream and packet oriented transports?
>
>
> over a message-based transport, so this is something that can simply always
> be done. Thus, can we just write a disclaimer in one of our documents,
> recommending that any TAPS-supporting systems can provide stream-based
> transport on top of the message based transport too, but that its users
> must be aware of limitations that arise from streams (such as HOL blocking
> delay, no ALF, ..)?
>
> Cheers,
> Michael
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Jul 2014 11:37:06 -0700

On 7/11/2014 7:53 AM, Fred Baker (fred) wrote:
> interface.

Except for efficiency. A messages on streams can induce delays for 
reordering and error recovery that the messages might be able to tolerate.

I.e., that's why we have DCCP and SCTP alternatives.

 > When I want to send a large message, such as a file, the
> difference between the two is difficult to discern: either way one
> slices that cookie, one has a lot of transport PDUs being sent; the only
> real difference is at the receiving end, which might want to receive the
> stream as it arrives or the message when it has completely arrived.

Even when you send a file, there is a difference depending on the errors 
and reordering in the stream. If the source is stable (not ephemeral) 
and has no cost to the order of access, the most efficient way is to 
send the entire file and go back to fill in the holes as you go. Other 
ways induce stalls to ensure that the window 'in memory' is small, which 
made sense when RAM was costly.

I.e., there are a LOT of trade-offs in the overall system, and it 
depends on way the *entire* system is being used as a whole.

> IMHO, the API will do well to let the client advise it regarding what
> type of interface it wants, and go with it.

+1

Joe

>
> On Jun 27, 2014, at 7:45 AM, Michael Welzl <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Hi,
>>
>> I changed the subject because this is not about the chartering
>> discussion anymore - it's beginning our work   :-)
>>
>>
>> On 27. juni 2014, at 16:21, Toby Moncaster
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> [snip]
>>
>>
>>>>>>>     - message atomicity
>>>>>
>>>>> What's that? That multiple messages are not combined into one
>>>>> packet? This plays a role for an application only when there is
>>>>> significant loss (I think). Wouldn't it be nice to have a system
>>>>> that provides atomicity only when needed and otherwise saves header
>>>>> overhead? I would vote against exposing that. Either way, I vote it
>>>>> off the list that goes in the charter, it's not an obvious service
>>>>> to me.
>>>
>>> To some extent I agree here. But is there any way we can correctly
>>> express the differences between stream and packet oriented transports?
>>
>> It seems to me to be straightforward to provide a stream-based
>> transport over a message-based transport, so this is something that
>> can simply always be done. Thus, can we just write a disclaimer in one
>> of our documents, recommending that any TAPS-supporting systems can
>> provide stream-based transport on top of the message based transport
>> too, but that its users must be aware of limitations that arise from
>> streams (such as HOL blocking delay, no ALF, ..)?
>>
>> Cheers,
>> Michael
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Michael Welzl <[email-masked]>
Date: Sat, 12 Jul 2014 09:47:00 +0200

>> type of interface it wants, and go with it.

Sure! But my point was that a byte stream can always be constructed over a packet stream for those who want it, at the potential loss of some efficiency. Vice versa doesn't make much sense to me - messages over a byte stream that then is split into packets that are sent over the networks is just silly. Yes certainly many apps do that over TCP (because TCP gives them many other good things and mostly works), but that sort of mismatch is what TAPS could help solve.

Hence, what I'd suggest is to not even consider "byte stream" in TAPS discussions - e.g. as a "service" or anything like that. Certainly, yes, a TAPS-based interface can always provide one.

As for Structured Streams, it's a nice paper but I never saw how this is much different from SCTP... anyway, bringing that into the discussion blends the *byte stream* that we're talking about here with *multi-streaming*  (which is what Structured Streams is about), which are really two separate things despite the name similarity. Multi-streaming can be (and is in fact best) done with messages, not a byte stream. As always, one can stack a byte stream on top with a possible efficiency loss.

Cheers,
Michael

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 12 Jul 2014 19:12:59 +0000

On Jul 12, 2014, at 12:47 AM, Michael Welzl <[email-masked]> wrote:

> As for Structured Streams, it's a nice paper but I never saw how this is much different from SCTP... 

Is that a bad thing?

---

From: Michael Welzl <[email-masked]>
Date: Sun, 13 Jul 2014 10:16:11 +0200

>> As for Structured Streams, it's a nice paper but I never saw how this is much different from SCTP... 

For the paper perhaps, in terms of innovation, as it doesn't talk much about SCTP IIRC...
But my intention was not to criticize the paper. I just meant that it's similar to multi-streaming in SCTP and thus probably not necessary to consider as yet another transport for TAPS to think about.

Cheers,
Michael

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 13 Jul 2014 17:39:58 +0000

On Jul 13, 2014, at 1:16 AM, Michael Welzl <[email-masked]> wrote:

> For the paper perhaps, in terms of innovation, as it doesn't talk much about SCTP IIRC…

OK. There are at least two ways one can approach this kind of technology: from the perspective of requirements, and from the perspective of innovation. A problem I have with academic papers is that they often innovate for innovation’s sake; they want desperately to create something novel, and will often say repeatedly that whatever their innovation is is novel, as if saying it frequently makes it so. My question is not whether it is novel, unless the novelty represents and actual improvement. My question is whether it meets the requirements.

In this case, we have a mechanism that carries data in IP datagrams. The datagrams fundamentally carry one of two kinds of content: messages that are exchanged between communicating peers, such as a BGP exchange might, and streams of data that might carry on interminably, such as an interactive exchange or an A/V application might. A stream must be delivered in sequence; messages might accept delivery out of sequence, or even unreliability. In between, the transport turns application data into IP datagrams and back into application data.

The way the transport distinguishes between messages and streams, if it does at all, is its designer’s call. But to say that the needs of two classes of applications are irrelevant because one can be created out of the other - which is the model that TCP used, and the model Sequenced packet used, and the model you propose here - targets the transport at that class of application. I think we’re far better off recognizing that there are multiple kinds of applications, and making an API that works well with either or any of them If that means that the API implements RFC 2126 internally to carry messages over a stream transport, so be it. If it means that the transport internally carries chunks, as SCTP does, and knows whether they are intended to be streams or messages, so be it. But making it an application layer problem doesn’t come across to me as having looked at it from the perspective of the requirements of the application layer.

---

From: Michael Welzl <[email-masked]>
Date: Mon, 14 Jul 2014 00:19:14 +0200

> The way the transport distinguishes between messages and streams, if it does at all, is its designer’s call. But to say that the needs of two classes of applications are irrelevant because one can…

I agree with all of that (and have a feeling that you misunderstood me  :-)   ).

Cheers,
Michael