Subject: [Taps] Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Wed, 25 Jun 2014 06:15:49 -0700

Benoit Claise has entered the following ballot position for
charter-ietf-taps-00-00: Block

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.

1. (somehow similar to Alissa's COMMENT)
The charter should mention that the WG will first analyze the set of
relevant criteria.
I guess that this is what's meant by "services" in this entry but
"services" is an overloaded term.

  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.

Brian Trammell, during his IESG/IAB retreat presentation called that
"dimensions of transport":
    - 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
    - path-state propagation (NAT/FW)

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.

I'm an application designer, I care for a transport that will provide
me:
    - message atomicity
    - head-of-line blocking avoidance
    - sub-channels
    - full reliability
    - loss-sensitive congestion control

How do we call those 5 things? criteria?
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.

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.

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

OLD:

- Specify a subset of those services identified in item 1, which 
  end systems supporting TAPS need to provide and provide guidance 
  on choosing among available mechanisms and protocols to obtain 
  a given transport service.

NEW:
- Specify a subset of those transport services identified in item 1,
which 
  end systems supporting TAPS need to provide and provide guidance 
  on choosing among available mechanisms and protocols.

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.

2.

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

I don't understand what "deliver" mean in the first sentence.

3.
It seems that there are multiple problem statements, with two different
solution tracks: one for existing transport protocols, another one for
new transport protocols.
Both rely on the identifying the transport services/criteria, which is
good.
- existing transport protocols: as you wrote "different protocols can
provide the same services in different ways"
- existing transport protocols: how do we know if endpoints and the path
support those?
- new transport protocol development (I got this from my discussion with
Brian, true it's not really mentioned in the charter)

In your paragraph to which problem statement "this problem" refers to?

    There are many ways in which this problem could be addressed; 
    while it may not yet be clear what the best way forward could 
    be, any approach to provide a richer set of transport services 
    to applications will have to begin with the identification of 
    the services that current transport protocols provide.

Depending on what "this problem" refers to, the solution might be
     new transport middle layer
     API services discovery
    OAM services discovery
    etc.   

Discussing with Spencer, it means: "which transport building blocks work
for me".
So this paragraph should be rephrased.
Possible solution

OLD:

    There are many ways in which this problem could be addressed; 
    while it may not yet be clear what the best way forward could 
    be, any approach to provide a richer set of transport services 
    to applications will have to begin with the identification of 
    the services that current transport protocols provide.

NEW (this paragraph would make more sense after the 3 bullet points "the
Working Group will")

    The Working Group deliverables will help an application 
    programmer identify the important transport services for his
    application and determine if those transport services are available 
    on the end points and along the path in the network. An approach to 
    provide a richer set of transport services to applications (which 
    could be part of a future charter) has to begin with the
identification of 
    the services that current transport protocols provide.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 26 Jun 2014 18:42:18 -0500

As you'll notice in Benoit's comments below, he's finding "service" and 
"transport service" to be fairly vague. He ends up proposing that the 
charter would not use "service" without an adjective, and that the 
charter use "transport service" to describe "transport protocol + 
criterion", so in a fairly constrained way.

I'd like to use terms in the charter that won't confuse the heck out of 
the average reader, so I'm curious what the folks on the TAPS mailing 
list think (after looking at his proposed text changes below, of course, 
because we would never express an opinion without considering context).

I should also mention that a couple of ADs have asked me if TAPS can be 
described as a session layer. One of my definitions of "session layer" 
is "surviving transport-layer disconnections and reconnections", and I 
haven't seen people talking about that on e-mail, so I'm thinking 
calling it a session layer wouldn't help (replacing a confusing term 
with another confusing term).

I kept Benoit on as CC:, so he can say "yes, that helps", or "no, that's 
worse", but dropped the rest of the IESG from this part of the 
conversation, in case this turns out to be a bikeshed.

Spencer

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 26 Jun 2014 18:50:57 -0500

...

>    and protocols to obtain a certain transport service.

Keeping in mind that most of you haven't seen the TAPS-related slide 
deck that the IESG and IAB discussed during our day together in Cancun 
... there's probably not an INFINITE number of transport services to 
think about. I'm fine with the resulting working group coming up with 
the list it will use for subsequent work, but perhaps including a 
proposed list as a starting point might be helpful.

> Btw, adding this list to the charter, as a starting point, would make

If we added this list, or something close to it, to the charter, would 
someone object (with reasoned objections, of course)?

Thanks,

Spencer

---

From: Toby Moncaster <[email-masked]>
Date: Fri, 27 Jun 2014 09:02:06 +0100

I would have no strong objection so long as it is made really clear that this is a starting point and not an exhaustive list. Also these are to some extent a list of desired outcomes that the actual transport services will provide.

Toby

On 27 Jun 2014, at 00:50, Spencer Dawkins <[email-masked]> wrote:

> Keeping in mind that most of you haven't seen the TAPS-related slide deck that the IESG and IAB discussed during our day together in Cancun ... there's probably not an INFINITE number of transport services to think about. I'm fine with the resulting working group coming up with the list it will use for subsequent work, but perhaps including a proposed list as a starting point might be helpful.
> 
> If we added this list, or something close to it, to the charter, would someone object (with reasoned objections, of course)?
> 
> Thanks,
> 
> Spencer
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Michael Welzl <[email-masked]>
Date: Fri, 27 Jun 2014 11:33:46 +0200

Hi,

I'm afraid this'll have to be long; in line:

On 27. juni 2014, at 01:42, Spencer Dawkins <[email-masked]> wrote:

> As you'll notice in Benoit's comments below, he's finding "service" and "transport service" to be fairly vague. He ends up proposing that the charter would not use "service" without an adjective, and that the charter use "transport service" to describe "transport protocol + criterion", so in a fairly constrained way.

Well, frankly, I don't think that's moving the charter in a good direction. Talking about services rather than protocols makes it clearer that we don't want to bind applications to protocols anymore, but rather to what protocols provide to applications that use them (see, even that sentence gets a bit strange if I avoid the word service - and if we don't use that word here, what else is it that a protocol offers / provides to applications?).

> I'd like to use terms in the charter that won't confuse the heck out of the average reader, so I'm curious what the folks on the TAPS mailing list think (after looking at his proposed text changes below, of course, because we would never express an opinion without considering context).

I know that the word "service" is very often vaguely used and dislike the word myself for that - but in fact, here, I think it really is the best choice. It's about what an application gets from a protocol - e.g. "characteristics" describes a protocol, i.e. is about internals that may not be relevant to an application. Indeed, the email below shows some of that misunderstanding, based on Brian's list. I'll explain below.

As for avoiding confusion, having a shortened version of Brian's list as examples should do it - you see the list, you know what this is about.

> I should also mention that a couple of ADs have asked me if TAPS can be described as a session layer. One of my definitions of "session layer" is "surviving transport-layer disconnections and reconnections", and I haven't seen people talking about that on e-mail, so I'm thinking calling it a session layer wouldn't help (replacing a confusing term with another confusing term).

+1 to your opinion!

> I kept Benoit on as CC:, so he can say "yes, that helps", or "no, that's worse", but dropped the rest of the IESG from this part of the conversation, in case this turns out to be a bikeshed.
> 
> Spencer
> 

There you go, he called it "dimensions", not "services", so the list is broader in scope. I agree with including parts of his list in the charter, as examples of services, but not the whole list because IMO some items don't belong there. I'll go through them item by item below, applying the following criterion: would an application programmer ever want to say "yes" or "no" to this, without trying to optimize for specific environment conditions? First, we don't want to replace complexity with more complexity, so not exposing absolutely every detail is part of the point here. Second, programmers who prefer to write code themselves that optimizes for specific environments are probably not the typical "customers" of TAPS - probably such folks will want to continue choosing and configuring their protocol directly. I'm not saying TAPS is meant to be sub-optimal :-)  I'm saying it's meant to be able to automatize optimizing for the path, and so we should probably only expose things that are related to application requirements, irrespective of the path.

Obviously, we're getting into a sort of discussion that we should have in the WG-to-be, not now. But my point is: if the group should at some point decide that what I say above is the way to go, then replacing "service" with "protocol" etc. gets in the way, and so does the full list of Brian.

As I go through the list, I also raise questions about the items I criticize, but I don't want to discuss them yet: this is just to highlight that these items can create a confusion and should be removed from the list that goes in the charter.

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

>>     - stream fragmentation

Is this the opposite of atomicity? (then, why is it "stream", not "message" fragmentation?). If it is, I wouldn't want to include it in the list for the reasons I gave about atomicity above.

>>     - sequence preservation

Definitely a service! This absolutely depends on your application and nothing else.

>>     - head-of-line blocking avoidance

Not a service at all, and potentially harmful to expose. This is a performance optimization, a benefit that you can get if a protocol, set of protocols, "session layer", whatever you want to call it, does its job right. Why do I say "potentially harmful"? If an application would select "I don't need sequence preservation" and "you must give me HOL blocking avoidance", then this combination can be provided with SCTP, but we have no way to use normal TCP as a fall-back because it comes with HOL blocking. So the whole system is limited by this set of choices. How harmful is such a fall-back however? It's just some extra delay in a best effort Internet. Just the kind of flexibility that we may want to have.

>>     - sub-channels

Not a service. You can get the benefits of sub-channels without exposing them. See:
http://heim.ifi.uio.no/michawe/research/publications/globecom2011.pdf
for a proof of concept. Indeed, on what basis does an application say "a sub-channel please"? This is like saying "over UDP please". You shouldn't have to care.

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

>>     - delay-sensitive congestion control

"loss-sensitive congestion control" isn't a good name for a service because it indicates that there would be less loss, but in fact delay-sensitive congestion controllers tend to lose less  :-)    The choice of a loss-sensitive vs. delay-sensitive congestion controller (to use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a choice of a trade-off between throughput (potentially less, with LEDBAT) vs. delay (also potentially less, with LEDBAT).

So, first of all, I'd remove "loss-sensitive congestion control" from the list.

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

>>     - endpoint address agility

I'm not sure. Unsure enough to recommend removing it from the list.

>>     - privacy and integrity

See the discussion on security: I'd rather have it removed (given that this is just a list of examples, we can be rather restrictive about what goes in it).

>>     - path-state propagation (NAT/FW)

As with security, not sure how much of this / in which form we'd want to expose, and so I'd feel better if it were removed.

>> Btw, adding this list to the charter, as a starting point, would make

So, to summarize, here's the complete list that I suggest:

- sequence preservation
- various degrees of reliability
- low delay vs. high throughput

Yes it's short, but for a list of examples, that could be ok?

>>     - loss-sensitive congestion control

Wouldn't you rather say:
- high throughput (don't care so much about low delay)
- full reliability
- sequence preservation doesn't matter to me
... and have a system underneath automatically gives you head-of-line blocking avoidance and uses loss-sensitive congestion control?
(Ideally, that system would also use sub-channels if they do improve performance, and provides message atomicity only if this is a benefit, i.e. only if there is significant loss)

>> How do we call those 5 things? criteria?

A mess?

>> and LEDBAT provides low-priority "scavenger" communication.

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

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

>>   on choosing among available mechanisms and protocols.

Agreed.

>>   end system and path support), in order to provide a basis for

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.

>> I don't understand what "deliver" mean in the first sentence.

- hence I replaced it with "provide" above.

>> Discussing with Spencer, it means: "which transport building blocks work

This block above has me a bit confused, I think I lack context, so I won't comment on it.

>>     the services that current transport protocols provide.

Agreed; I like this change a lot, it's much more concrete and reflects our intention IMO.

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

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 27 Jun 2014 12:01:49 +0200

I have no problem with adding something close to it (for some definition of "close"  :-)   ), but I don't want to add this list as it stands. This is explained in another thread answering Benoit Claise, where I explain how only a few items in Brian's list are what I would also call a "service". While this discussion should happen later, it'd be nice to have a shorter, more homogeneous list in the charter. For those interested in the thread but not on the TAPS list, see:
http://www.ietf.org/mail-archive/web/taps/current/msg00206.html

It boils down to the following charter change:

OLD:

NEW, PROPOSED BY BENOIT:

NEW, PROPOSED BY ME:

Cheers,
Michael

---

From: [email-masked]
Date: Fri, 27 Jun 2014 12:19:41 +0100

I kind of thought of this as "transport mechanisms" to support existing
"transport protocols"?

Gorry

> I would have no strong objection so long as it is made really clear that
> this is a starting point and not an exhaustive list. Also these are to
> some extent a list of desired outcomes that the actual transport services
> will provide.
>
> Toby
>

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 27 Jun 2014 08:42:48 -0500

> I'm afraid this'll have to be long; in line:

Hi, Michael,

This was long, but helpful.

I agree with the point about the working group needing to work through 
the list, and that not being a requirement for actual charter approval. 
Would other folk be OK with naming a couple of examples, rather than a 
starting list, as Benoit and I had been discussing?

On one point (that Michael said he was confused about below, so maybe 
worth explaining better), Benoit and I spent about 20 minutes talking 
before he balloted his block, and one thing we talked about was the 
difference between an application knowing what's available on a platform 
and knowing what's available on the path between two endpoints (so, if I 
can send UDP to any port to Benoit, but a firewall between me and 
Michael drops all UDP except for port 53, both of those facts are relevant).

This is what we meant when Benoit said "which transport building blocks 
work for me" below.

And thanks for staying engaged. I appreciate it.

Spencer

> On 27. juni 2014, at 01:42, Spencer Dawkins 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>> As you'll notice in Benoit's comments below, he's finding "service" 
>> and "transport service" to be fairly vague. He ends up proposing that 
>> the charter would not use "service" without an adjective, and that 
>> the charter use "transport service" to describe "transport protocol + 
> Well, frankly, I don't think that's moving the charter in a good 
> direction. Talking about services rather than protocols makes it 
> clearer that we don't want to bind applications to protocols anymore, 
> but rather to what protocols provide to applications that use them 
> (see, even that sentence gets a bit strange if I avoid the word 
> service - and if we don't use that word here, what else is it that a 
> protocol offers / provides to applications?).
>
>
>> I'd like to use terms in the charter that won't confuse the heck out 
>> of the average reader, so I'm curious what the folks on the TAPS 
>> mailing list think (after looking at his proposed text changes below, 
>> of course, because we would never express an opinion without 
>> considering context).
>
> I know that the word "service" is very often vaguely used and dislike 
> the word myself for that - but in fact, here, I think it really is the 
> best choice. It's about what an application gets from a protocol - 
> e.g. "characteristics" describes a protocol, i.e. is about internals 
> that may not be relevant to an application. Indeed, the email below 
> shows some of that misunderstanding, based on Brian's list. I'll 
> explain below.
>
> As for avoiding confusion, having a shortened version of Brian's list 
> as examples should do it - you see the list, you know what this is about.
>
>
>> I should also mention that a couple of ADs have asked me if TAPS can 
>> be described as a session layer. One of my definitions of "session 
>> layer" is "surviving transport-layer disconnections and 
>> reconnections", and I haven't seen people talking about that on 
>> e-mail, so I'm thinking calling it a session layer wouldn't help 
>> (replacing a confusing term with another confusing term).
>
> +1 to your opinion!
>
>
>> I kept Benoit on as CC:, so he can say "yes, that helps", or "no, 
>> that's worse", but dropped the rest of the IESG from this part of the 
> There you go, he called it "dimensions", not "services", so the list 
> is broader in scope. I agree with including parts of his list in the 
> charter, as examples of services, but not the whole list because IMO 
> some items don't belong there. I'll go through them item by item 
> below, applying the following criterion: would an application 
> programmer ever want to say "yes" or "no" to this, without trying to 
> optimize for specific environment conditions? First, we don't want to 
> replace complexity with more complexity, so not exposing absolutely 
> every detail is part of the point here. Second, programmers who prefer 
> to write code themselves that optimizes for specific environments are 
> probably not the typical "customers" of TAPS - probably such folks 
> will want to continue choosing and configuring their protocol 
> directly. I'm not saying TAPS is meant to be sub-optimal :-)  I'm 
> saying it's meant to be able to automatize optimizing for the path, 
> and so we should probably only expose things that are related to 
> application requirements, irrespective of the path.
>
> Obviously, we're getting into a sort of discussion that we should have 
> in the WG-to-be, not now. But my point is: if the group should at some 
> point decide that what I say above is the way to go, then replacing 
> "service" with "protocol" etc. gets in the way, and so does the full 
> list of Brian.
>
> As I go through the list, I also raise questions about the items I 
> criticize, but I don't want to discuss them yet: this is just to 
> highlight that these items can create a confusion and should be 
> removed from the list that goes in the charter.
>
>
>>>     - 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.
>
>
>>>     - stream fragmentation
>
> Is this the opposite of atomicity? (then, why is it "stream", not 
> "message" fragmentation?). If it is, I wouldn't want to include it in 
> the list for the reasons I gave about atomicity above.
>
>
>>>     - sequence preservation
>
> Not a service at all, and potentially harmful to expose. This is a 
> performance optimization, a benefit that you can get if a protocol, 
> set of protocols, "session layer", whatever you want to call it, does 
> its job right. Why do I say "potentially harmful"? If an application 
> would select "I don't need sequence preservation" and "you must give 
> me HOL blocking avoidance", then this combination can be provided with 
> SCTP, but we have no way to use normal TCP as a fall-back because it 
> comes with HOL blocking. So the whole system is limited by this set of 
> choices. How harmful is such a fall-back however? It's just some extra 
> delay in a best effort Internet. Just the kind of flexibility that we 
> may want to have.
>
>
>>>     - sub-channels
>
> for a proof of concept. Indeed, on what basis does an application say 
> "a sub-channel please"? This is like saying "over UDP please". You 
> shouldn't have to care.
>
>
>>>     - full reliability
> "various degrees of reliability" or "various forms of reliability" or 
> "full / latency-limited / no reliability"
> "loss-sensitive congestion control" isn't a good name for a service 
> because it indicates that there would be less loss, but in fact 
> delay-sensitive congestion controllers tend to lose less  :-)    The 
> choice of a loss-sensitive vs. delay-sensitive congestion controller 
> (to use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a 
> choice of a trade-off between throughput (potentially less, with 
> LEDBAT) vs. delay (also potentially less, with LEDBAT).
>
> 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".
>
>
> See the discussion on security: I'd rather have it removed (given that 
> this is just a list of examples, we can be rather restrictive about 
> what goes in it).
>
>
> As with security, not sure how much of this / in which form we'd want 
> to expose, and so I'd feel better if it were removed.
>
>
> ... and have a system underneath automatically gives you head-of-line 
> blocking avoidance and uses loss-sensitive congestion control?
> (Ideally, that system would also use sub-channels if they do improve 
> performance, and provides message atomicity only if this is a benefit, 
> i.e. only if there is significant loss)
>
>
> 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:
>
> 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:
> 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...
>
> Cheers,
> Michael
>

---

From: Michael Welzl <[email-masked]>
Date: Fri, 27 Jun 2014 16:04:20 +0200

> This was long, but helpful.

Thanks - and apologies: I know that such a long email is a pain for everyone, especially at this stage, but I saw no other way...

> I agree with the point about the working group needing to work through the list, and that not being a requirement for actual charter approval. Would other folk be OK with naming a couple of examples, rather than a starting list, as Benoit and I had been discussing?

Sure; but my point is that having a too "open" list potentially sets up the group in the wrong direction.

> On one point (that Michael said he was confused about below, so maybe worth explaining better), Benoit and I spent about 20 minutes talking before he balloted his block, and one thing we talked about was the difference between an application knowing what's available on a platform and knowing what's available on the path between two endpoints (so, if I can send UDP to any port to Benoit, but a firewall between me and Michael drops all UDP except for port 53, both of those facts are relevant).
> 
> This is what we meant when Benoit said "which transport building blocks work for me" below.

Well, indeed, this is a design trade-off here that the group must figure out. Two example cases here:

1) My own preference: TAPS hides pretty much everything that's path-related from the application, and we say "if you do care about such details, don't use TAPS, use the protocol you wish."

2) Maybe someone else's, maybe Benoit's, preference: TAPS does not hide path-related information from the application.

In case 2), the outcome of TAPS is:
+ more useful
+ "richer"
- more complex
- less flexible in case someone wants to build a TAPS system that automatizes a lot of functions.

When writing a list of example transport services related to 1) and 2) above, the first list is simply shorter than the second. Whether we want 1) or 2) or where to draw the line between them is certainly a discussion for later, but my concern is: if we include an example list with items from 2) above in the charter, it's already decided that we will do 2). If we include only examples from 1) above, nothing stops us from going for 2) if the group wants to.

Maybe I'm over-complicating it - if my concern is unfounded and charters are flexible enough anyway and none of this really matters, by all means include whatever list you wish, noone here will have a huge problem with a list of examples anyway, I guess    :-)

Cheers,
Michael

---

From: Toby Moncaster <[email-masked]>
Date: Fri, 27 Jun 2014 15:21:23 +0100

I’m going to try and add some (hopefully) relevant comments inline :)

> I agree with the point about the working group needing to work through the list, and that not being a requirement for actual charter approval. Would other folk be OK with naming a couple of example…

I have a very strong preference for a set of examples. If we have too long a list I fear it might bias the actual outcome of the work we hope this WG will do!

> On one point (that Michael said he was confused about below, so maybe worth explaining better), Benoit and I spent about 20 minutes talking before he balloted his block, and one thing we talked abo…

OK, That makes sense. This is a difference between “Which services are available in my transport stack” and “Which services can I use on a particular connection”. One of the points of thinking in terms of falling back to e.g. TCP is to address this problem. 

Also to my way of thinking the purpose of describing these as “services” is to abstract away the actual mechanism that delivers the service. In turn this gives the potential for the TAPS-aware transport to select the transport protocol that most closely matches the desired set of services

>> Well, frankly, I don't think that's moving the charter in a good direction. Talking about services rather than protocols makes it clearer that we don't want to bind applications to protocols anymo…

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 

>> As for avoiding confusion, having a shortened version of Brian's list as examples should do it - you see the list, you know what this is about.

yes

>>> I should also mention that a couple of ADs have asked me if TAPS can be described as a session layer. One of my definitions of "session layer" is "surviving transport-layer disconnections and rec…

+1 Session layer will just totally throw everyone!

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

To some extent I agree here. But is there any way we can correctly express the differences between stream and packet oriented transports?

>> Definitely a service! This absolutely depends on your application and nothing else.

agree

>> Not a service at all, and potentially harmful to expose. This is a performance optimization, a benefit that you can get if a protocol, set of protocols, "session layer", whatever you want to call…

agree with Michael, although I’m not sure I completely agree with how he expresses the objection

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

>> So, first of all, I'd remove "loss-sensitive congestion control" from the list.

Slightly disagree here. But can’t quite put it into words

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

>> I'm not sure. Unsure enough to recommend removing it from the list.

No views either way. But the fact there is any uncertainty is in itself a good reason not to list this as a service in the charter (since that effectively is making the decision that it IS a service)

>> See the discussion on security: I'd rather have it removed (given that this is just a list of examples, we can be rather restrictive about what goes in it).

Agree. Remove this for the initial list

>> As with security, not sure how much of this / in which form we'd want to expose, and so I'd feel better if it were removed.

Agree. Remove this for the initial list

>> - low delay vs. high throughput

I’d rephrase this as:

- ordering/sequence preservation
- degree of reliability 
- latency vs throughput

>>>> How do we call those 5 things? criteria?

If TAPS is ever to be successful we have to get and keep the application developers on side. So I would say that application designers might have a list of desired outcomes for their application and TAPS is about marrying that up with the underlying services that lead to those outcomes

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

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

>>>>   on choosing among available mechanisms and protocols.

agree as well

>>   end system and path support), in order to provide a basis for

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.

>> This block above has me a bit confused, I think I lack context, so I won't comment on it.

addressed above

>> Agreed; I like this change a lot, it's much more concrete and reflects our intention IMO.

Yes. Agreed

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

---

From: Michael Welzl <[email-masked]>
Date: Fri, 27 Jun 2014 16:38:10 +0200

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]> 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…

I agree. Putting that definition in there would be nice.

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

Agree.

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

Agree.

> - ordering/sequence preservation

Agree, this is nicer!

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

Okay, fine by me. I don't have a strong opinion here either way.

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

Agreed

Agreed.

Agreed.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 27 Jun 2014 16:45:08 +0200

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:

[snip]

> 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

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 27 Jun 2014 16:50:54 +0200

Hi,

A few comments inline. The short summary is that I agree with most of 
the main points below and also prefer having a list of examples.

Anna

On 2014-06-27 16:21, Toby Moncaster wrote:
> I'm going to try and add some (hopefully) relevant comments inline :)
>
>
> On 27 Jun 2014, at 14:42, Spencer Dawkins 
>> I agree with the point about the working group needing to work 
>> through the list, and that not being a requirement for actual charter 
>> approval. Would other folk be OK with naming a couple of examples, 
>> rather than a starting list, as Benoit and I had been discussing?
>
> I have a very strong preference for a set of examples. If we have too 
> long a list I fear it might bias the actual outcome of the work we 
> hope this WG will do!

I agree.

>> difference between an application knowing what's available on a 
>> platform and knowing what's available on the path between two 
>> endpoints (so, if I can send UDP to any port to Benoit, but a 
>> firewall between me and Michael drops all UDP except for port 53, 
>> both of those facts are relevant).
>
> OK, That makes sense. This is a difference between "Which services are 
> available in my transport stack" and "Which services can I use on a 
> particular connection". One of the points of thinking in terms of 
> falling back to e.g. TCP is to address this problem.
>
> Also to my way of thinking the purpose of describing these as 
> "services" is to abstract away the actual mechanism that delivers the 
> service. In turn this gives the potential for the TAPS-aware transport 
> to select the transport protocol that most closely matches the desired 
> set of services
>
>>
>>> <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> and "transport service" to be fairly vague. He ends up proposing 
>>>> that the charter would not use "service" without an adjective, and 
>>>> that the charter use "transport service" to describe "transport 
>>>> protocol + criterion", so in a fairly constrained way.
>>>
>>> clearer that we don't want to bind applications to protocols 
>>> anymore, but rather to what protocols provide to applications that 
>>> use them (see, even that sentence gets a bit strange if I avoid the 
>>> word service - and if we don't use that word here, what else is it 
>>> that a protocol offers / provides to applications?).
>
>
> 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.

>>>
>>>
>>>> I'd like to use terms in the charter that won't confuse the heck 
>>>> out of the average reader, so I'm curious what the folks on the 
>>>> TAPS mailing list think (after looking at his proposed text changes 
>>>> below, of course, because we would never express an opinion without 
>>>> considering context).
>>>
>>> I know that the word "service" is very often vaguely used and 
>>> dislike the word myself for that - but in fact, here, I think it 
>>> really is the best choice. It's about what an application gets from 
>>> a protocol - e.g. "characteristics" describes a protocol, i.e. is 
>>> about internals that may not be relevant to an application. Indeed, 
>>> the email below shows some of that misunderstanding, based on 
>>> Brian's list. I'll explain below.
>>>
>>> As for avoiding confusion, having a shortened version of Brian's 
>>> list as examples should do it - you see the list, you know what this 
>>> is about.
>
> yes
>
>>>
>>>
>>>> I should also mention that a couple of ADs have asked me if TAPS 
>>>> can be described as a session layer. One of my definitions of 
>>>> "session layer" is "surviving transport-layer disconnections and 
>>>> that's worse", but dropped the rest of the IESG from this part of 
>>>> the conversation, in case this turns out to be a bikeshed.
>>>>
>>>> Spencer
>>>>
>>> optimize for specific environment conditions? First, we don't want 
>>> to replace complexity with more complexity, so not exposing 
>>> absolutely every detail is part of the point here. Second, 
>>> programmers who prefer to write code themselves that optimizes for 
>>> specific environments are probably not the typical "customers" of 
>>> TAPS - probably such folks will want to continue choosing and 
>>> configuring their protocol directly. I'm not saying TAPS is meant to 
>>> be sub-optimal :-)  I'm saying it's meant to be able to automatize 
>>> optimizing for the path, and so we should probably only expose 
>>> things that are related to application requirements, irrespective of 
>>> the path.
>>>
>>> Obviously, we're getting into a sort of discussion that we should 
>>> have in the WG-to-be, not now. But my point is: if the group should 
>>> at some point decide that what I say above is the way to go, then 
>>> replacing "service" with "protocol" etc. gets in the way, and so 
>>> does the full list of Brian.
>>>
>>> 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?
>

I agree that this could be a good example of a useful service. From an 
application perspective, I would rather use message than packet though. 
Message preservation, message framing, preserving message boundaries?

>>> "message" fragmentation?). If it is, I wouldn't want to include it 
>>> in the list for the reasons I gave about atomicity above.
>>>
>>>
>>>>>     - sequence preservation
>>>
>>> set of protocols, "session layer", whatever you want to call it, 
>>> does its job right. Why do I say "potentially harmful"? If an 
>>> application would select "I don't need sequence preservation" and 
>>> "you must give me HOL blocking avoidance", then this combination can 
>>> be provided with SCTP, but we have no way to use normal TCP as a 
>>> fall-back because it comes with HOL blocking. So the whole system is 
>>> limited by this set of choices. How harmful is such a fall-back 
>>> however? It's just some extra delay in a best effort Internet. Just 
>>> the kind of flexibility that we may want to have.
>
> agree with Michael, although I'm not sure I completely agree with how 
> he expresses the objection
>
>>>
>>>
>>>>>     - sub-channels
>>>
>>> for a proof of concept. Indeed, on what basis does an application 
>>> say "a sub-channel please"? This is like saying "over UDP please". 
>>> You shouldn't have to care.
>>>
>>>
>>>>>     - full reliability
>>> "various degrees of reliability" or "various forms of reliability" 
>>> or "full / latency-limited / no reliability"
> Hmmm. I'd rather we had something like "Degree of reliability from 
> unreliable to full reliability."
>
>>>
>>>
> Slightly disagree here. But can't quite put it into words

I would also remove "loss-sensitive congestion control"

> Perhaps this would best be expressed as "Trading off latency and 
> throughput"
>
>
>>>
>>>
> No views either way. But the fact there is any uncertainty is in 
> itself a good reason not to list this as a service in the charter 
> (since that effectively is making the decision that it IS a service)
>
>>>
>>>
>>>>>     - privacy and integrity
>>>
>>> See the discussion on security: I'd rather have it removed (given 
>>> that this is just a list of examples, we can be rather restrictive 
>>> about what goes in it).
>
>>> As with security, not sure how much of this / in which form we'd 
>>> want to expose, and so I'd feel better if it were removed.
>
> I'd rephrase this as:

All good updates I think.

>>> ... and have a system underneath automatically gives you 
>>> head-of-line blocking avoidance and uses loss-sensitive congestion 
>>> control?
>>> performance, and provides message atomicity only if this is a 
>>> benefit, i.e. only if there is significant loss)
>>>
>>>
> If TAPS is ever to be successful we have to get and keep the 
> application developers on side. So I would say that application 
> designers might have a list of desired outcomes for their application 
> and TAPS is about marrying that up with the underlying services that 
> lead to those outcomes
>
>>>
>>>
> I actually think changing that to protocols might be a good thing, 
> since it highlights how complex the landscape has become.

I disagree. I agree with Michael here that we shoud stress that 
applications use services, not protocols. Also the examples talk about 
services not protocols so the proposed new wording is strange to me.

>>> 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:
>>>
> 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
>
>>> to say "provide a transport service", maybe "deliver" is a bad 
>>> choice of words here? So I suggest:
>>>
>>> NEW:
> 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
>
>>>
>>> Cheers,
>>> Michael
>>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 27 Jun 2014 16:56:09 +0200

Hi,

As this is now in a new thread I add my point from the very long mail.

Preserving message boundaries is a useful service so I think this could 
be a good example of a service. I guess that was what Brian was after. 
Some possible names: Message preservation, message framing, preserving 
message boundaries?

Anna

On 2014-06-27 16:45, Michael Welzl 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
>>>>
> 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
>
>
>

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 27 Jun 2014 17:07:41 +0200

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

>>>> 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:
>>>>
>>>> Disagree. "deliver a transport protocol" is weird. The intention 
>>>> was to say "provide a transport service", maybe "deliver" is a bad 
>> 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
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Jun 2014 10:53:22 -0700

> Some possible names: Message preservation, message framing, preserving

FWIW, I don't understand "preserving message boundaries" as a service.

Being a service means defining the information exchange - either it's a 
single, ordered stream of bytes or it's a set of messages.

I don't know if there's utility in defining another type which is "a 
continuous stream of bytes with separator boundaries", but AFAICT that 
mechanism is an artifact of using a bytestream to implement a message 
service - and IMO ought to be invisible to the service 'consumer'.

Joe

---

From: <[email-masked]>
Date: Sat, 28 Jun 2014 09:31:33 +0000

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]> on behalf of Anna Brunstrom <[email-masked]>
Sent: Saturday, 28 June 2014 1:07:41 AM
To: [email-masked]
Cc: [email-masked]; [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 27. juni 2014, at 16:21, Toby Moncaster <[email-masked]<mailto:[email-masked]>> wrote:

[snip]

    - full reliability

Agree.

Agree.

- sequence preservation

I’d rephrase this as:

Agree, this is nicer!

OLD:

NEW:

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:

NEW:

Agreed

OLD:

NEW:

NEW:

Agreed.

Agreed.

Cheers,
Michael

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

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Sat, 28 Jun 2014 06:08:00 -0400

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]
[email-masked]

> On Jun 28, 2014, at 5:31, <[email-masked]> wrote:
>

---

From: Aaron Falk <[email-masked]>
Date: Sat, 28 Jun 2014 10:46:28 -0400

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]

> 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]
> [email-masked]
>
> 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]> on behalf of Anna Brunstrom <
> [email-masked]>
> *Sent:* Saturday, 28 June 2014 1:07:41 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Taps] Charter bikeshed #1 - "transport service"
>
>  Hi,
>
> 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
>
>
> requirement to a specific mechanism. I'd rather use something like "low
> delay vs. high throughput”.
>
>
>  I actually think changing that to protocols might be a good thing, since
> it highlights how complex the landscape has become.
>
>
>
> 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:
>
>  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
>
>  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:
> 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]://www.ietf.org/mailman/listinfo/taps
>
>

---

From: Michael Welzl <[email-masked]>
Date: Sat, 28 Jun 2014 19:12:07 +0200

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]> 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]> wrote:

---

From: Michael Welzl <[email-masked]>
Date: Sun, 29 Jun 2014 11:42:17 +0200

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

---

From: Michael Welzl <[email-masked]>
Date: Sun, 29 Jun 2014 12:07:01 +0200

I hope the subject is ok  :)   now, to the point:

I agree, on both accounts.

Cheers,
Michael

---

From: <[email-masked]>
Date: Sun, 29 Jun 2014 11:48:18 +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"

Cheers,
Michael

On 28. juni 2014, at 19:12, Michael Welzl <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone

On 28. juni 2014, at 16:46, Aaron Falk <[email-masked]<mailto:[email-masked]>> wrote:

and

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

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,

Anna

[snip]

    - full reliability

Agree.

Agree.

- sequence preservation

I’d rephrase this as:

Agree, this is nicer!

OLD:

NEW:

OLD:

NEW:

NEW:

Agreed

OLD:

NEW:

NEW:

Agreed.

Agreed.

Cheers,
Michael

---

From: Eliot Lear <[email-masked]>
Date: Sun, 29 Jun 2014 09:05:41 -0400

Michael,

Probably a good idea to put out a clean version of what you believe we
have converged on. There's a lot of depth to this discussion, much in
the form of >>>>,

Eliot

On 6/29/14, 5:42 AM, Michael Welzl wrote:
> 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 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 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]
>>>>     <mailto:[email-masked]>> on behalf of Anna Brunstrom
>>>>     <[email-masked] <mailto:[email-masked]>>
>>>>     *To:* [email-masked] <mailto:[email-masked]>
>>>>     *Cc:* [email-masked] <mailto:[email-masked]>;
>>>>     [email-masked]
>>>>     <mailto:[email-masked]>
>>>>     Repeating one of my comments on the long mail to this more
>>>>     manageable version that Micheal produced while I was reading.
>>>>
>>>>     Anna
>>>>
>>>>>     <[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
>>>>>
>>>>>>>>     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"
>>>>>>>>     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”.
>>>>>>
>>>>>>>>     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.
>>>>
>>>>
>>>>
>>>>>>>>     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:
>>>>>>>>
>>>>>>     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
>>>>>>
>>>>>>>>     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:
>>>>>>>>     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
>>>>>
>>>>>
>>>>>

---

From: Michael Welzl <[email-masked]>
Date: Sun, 29 Jun 2014 15:32:15 +0200

On 29. juni 2014, at 15:05, Eliot Lear <[email-masked]> wrote:

> Michael,
> 
> Probably a good idea to put out a clean version of what you believe we have converged on. There's a lot of depth to this discussion, much in the form of >>>>,
> 
> Eliot

Great, suggestion, thanks!  It's below.
Note, this is only an update based on Benoit's comments - some others have proposed smaller changes (e.g., not starting the charter with "Conjointly, ..." ) and I'll leave those up to Spencer  (myself, I'm not even a native speaker after all).

Cheers,
Michael

ADD, NEAR THE BEGINNING OF THE CHARTER:

A Transport Service is any service provided by the transport layer that can only be correctly implemented with information from the application.

OLD:

NEW:
the set of Transport Services that are available to

OLD:

NEW:

- Identify Transport services provided by existing IETF 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:
  ordering/sequence preservation, degree of reliability, latency vs throughput.

OLD:

NEW:
- Specify a subset of those transport services identified in item 1,
which end systems supporting TAPS need to provide and provide guidance
  on choosing among available mechanisms and protocols.

OLD:

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

OLD:

OLD:

NEW:  Remove this sentence.

---

From: Michael Welzl <[email-masked]>
Date: Sun, 29 Jun 2014 15:38:05 +0200

> Note, this is only an update based on Benoit's comments - some others have proposed smaller changes (e.g., not starting the charter with "Conjointly, ..." ) and I'll leave those up to Spencer  (mys…

No need to search the list for even more comments  :-)   I should have said "some others in the IESG, as shown in the datatracker".

Cheers,
Michael

---

From: Brian Trammell <[email-masked]>
Date: Sun, 29 Jun 2014 23:59:34 +0200

hi Michael, all,

The charter as edited looks good to me, thanks for pulling all this together!

That's the end of the content of this message relevant to the chartering discussion. What follows is a bikeshed of a different color.

To clarify (or at least, to obfuscate differently) this ("Brian's") list:

    - message atomicity
    - stream fragmentation
    - sequence preservation

was presented at the IAB/IESG retreat as a list of (examples of) "dimensions", not "services", and on further thought they're not dimensions either (since they lack orthogonality -- some may be / are dependent on others); rather, they're characteristics. Some might be things applications wan, some might be things applications must tolerate. The idea is that the requirements of a given "service" are built from a set of characteristics.

In the original list from which this was taken, the common services SOCK_STREAM (over TCP) and SOCK_DGRAM (over UDP) were columns, where these were the rows, in a table showing the relationship between services and characteristics. The list was presented specifically to make the point that the space of existing transports is smaller than the space of useful transports (is smaller than the space of possible transport protocols).

Latency/throughput tradeoffs -- though these are important characteristics from an application standpoint and IMO a key reason to fix the interfaces to transport protocols in the first place -- didn't make it on to *this* list as is (they're hiding behind the congestion control items), mainly because neither SOCK_STREAM nor SOCK_DGRAM with the current sockets interface have such a thing.

That said, what to call these is a hard question with a set of arbitrarily bad answers, so I'm in full support of an abbreviated list of examples in the charter for the sake of clarity, as long as it's equally clear that the list is not intended to be complete.

Cheers,

Brian

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 30 Jun 2014 17:03:18 +0000

On 6/27/14, 8:45 AM, "Michael Welzl" <[email-masked]> wrote:

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

-- 
Joe Hildebrand

---

From: Michael Welzl <[email-masked]>
Date: Mon, 30 Jun 2014 23:53:01 +0200

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

Cheers,
Michael