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

From: <[email-masked]>
Date: Sun, 29 Jun 2014 21:13:47 +0000

I had to look up bikeshed and bikeshedding.

Wasn't there a recent RFC on not using slang?
________________________________
From: Michael Welzl <[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]>; [email-masked]; <[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

On Jun 28, 2014, at 5:31, <[email-masked]<mailto:[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]<mailto:[email-masked]>> on behalf of Anna Brunstrom <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, 28 June 2014 1:07:41 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[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]<mailto:[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 list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/taps