Transport Services
charter-ietf-taps-02

Changed charter milestone "Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG", set description to "Submit document(s) to be published as Proposed Standard to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG", set due date to March 2019 from November 2017

Changed charter milestone "Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support", set due date to November 2018 from March 2017

Changed charter milestone "Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms", set description to "Submit an Informational document defining a set of security-related Transport Services", set due date to July 2018 from November 2016, removed draft-ietf-taps-transports-usage-udp, draft-ietf-taps-transports, draft-ietf-taps-transports-usage from milestone

Added milestone "Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG", due November 2017, from current group milestones

Added milestone "Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support", due March 2017, from current group milestones

Added milestone "Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms", due November 2016, from current group milestones

[Ballot comment]
Agree with Ben and Adam.  I completely missed the subtleties of this change.

The "or" in the following excerpt really don't help
  The following topics are out of scope for this Working Group:
  - Extension, modification, or creation of transport or
    security protocols

What is out of scope: A, B, or maybe C or D?

Not blocking this recharter, but please improve.

[Ballot comment]
I agree with Ben that it would be valuable to add text to the charter that explicitly says what is being added (e.g., that the WG will "include transport security in its analysis"), rather than simply removing the prohibition.

[Ballot comment]
It would be nice to see the goals of the WG include descriptions of security properties for the described protocols.  I don't see any mention of security properties in comparison work for the WG.  Can you propose some text to add to the charter?

Thanks.

[Ballot comment]
Since the point of this update is to add security analysis to the charter scope, would it make sense to specify how the WG plans to engage with the security area, as is typically done when there is overlap or coupling between work in different WGs? E.g., will the WG be seeking early review from the security area on relevant drafts?

[Ballot comment]
Do I read correctly that the only change from the previous charter is to remove the paragraph about coordinating with TCPINC? If so, I'm not sure that change is important enough to justify rechartering, but I won't get in the way if other people agree with it.

[Ballot comment]
1) Define a set of Transport Services, prioritizing those provided by
  existing IETF protocols and congestion control mechanisms. As a
  starting point, the working group will consider services used
  between two endpoints.

What does "prioritizing" mean in the above sentence?
If I take your 4 examples (reliable delivery, no guarantee of order preservation (*) content privacy to in-path devices, and minimal latency.), how can you prioritize those? You can't, it's purely an application programmers choice.

Or maybe I missed something?
Don't you mean "identifying" instead of "prioritizing", or maybe "identifying the most common ones"

(*) btw, same remark as Adrian wrt "no" guarantee of order preservation as a service

[Ballot comment]
Wow, nearly every word of this text has changed since the IESG saw it
last!

I continue to have no objection to the formation of this WG, but I
have some wordwmithing suggestions.

---

You have two tones of the word "provided" in the following...

  We use the term "Transport
  Service" to mean an end-to-end facility provided by the
  transport layer that can only be correctly provided with
  information from the application. This information may be
  provided at design time, compile time, or run time and may
  include guidance from the application on whether the facility
  in question is required or simply a preference by the application.

"...provided with information" means "...given information". This
is reinforced by the next sentence saying "This informaiton is provided",
but you mean that it is the service that can only be correctly provided
if...

Furthermore, it is the service that is provided not the layer!

I suggest...
  We use the term "Transport
  Service" to mean an end-to-end facility provided by the
  transport layer. That service can only be provided correctly if
  information is supplied from the application. This information may be
  supplied at design time, compile time, or run time and may
  include guidance from the application on whether the facility
  in question is required or simply a preference by the application.

Finally, it is not clear what is being deisgned, compiled, or run. I
think you need to clarify that as well.

---

  Four examples of Transport Services are reliable delivery, no
  guarantee of order preservation, content privacy to in-path
  devices, and minimal latency.

Hmmm, "no guarantee" is a service? Where can I sign up for that?
I think it is a service level. The service is "ordered delivery of
data".

---

I think you have to decide whether you want to consider HTTP as a
transport protocol or an application protocol (or call it out as
both). Currently you have...

  Many firewalls only pass TCP
  and UDP and some only support HTTP over TCP.

...implying HTTP is a protocol carried by a transport protocol. An
impression reinforced by not including it in the previous list of
transport protocols.

But then...

  Applications,
  therefore, must always be able to fall back to TCP or UDP, or even
  HTTP in many cases, and once the application programmer has committed
  to making an application work on TCP or UDP or HTTP, there is little
  incentive to try other transport protocols before falling back.

...with "fall back to ... HTTP" implying HTTP is a transport protocol.

---

  how to
  discover which protocols are available for a given connection.

I wonder whether "connection" is the right word. I think you probably
mean "for the selected service between a given pair of end points."

---

  TAPS is not chartered to perform detailed analysis of the security
  aspects of transport protocols

This is fine, but will people lose track of the fact that security is
a transport service?

Added charter milestone "Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG", due March 2016

Added charter milestone "Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms", due June 2015

[Ballot comment]
Is it really necessary to begin the charter with an adverb, and one that every non-native speaker will need to look up in  a dictionary before trying to parse the sentence and work out to what it applies?

[Ballot comment]
Dave Thaler provided feedback about including HTTP during internal review that I've shared with the mailing list, but it wasn't captured in the datatracker.

It's at http://www.ietf.org/mail-archive/web/taps/current/msg00186.html.

[Ballot comment]

Also along the lines of Alissa's comment, I'd be interested in
whether and how the security properties of transports are to
be handled here. I hope they are, but it'd be good for a final
charter to mention that. One specific instance of that that'd
be useful to consider could be tcpinc. That might lead to
tricky timing, but OTOH, it'd be a pain if tcpinc were ignored
here.

Many applications actually fall back to (or just stick with) HTTP
for the reasons stated here, I don't know if it makes sense
to de-scope those applications here or not, but hope that
that's discussed during chartering (maybe it has been already?).

Stupidly, I find paragraphs and sentences that start with
an adverb, comma are harder to read. Annoyingly, for me,
this charter does that. Politely, I'd ask you to consider fixing
that:-)

[Ballot comment]
[Fixing a typo]

This could go for external review as-is. Some things to consider, either now or during external review:

I am not as concerned as Benoit that his clarifications need to be made; they won't hurt, but I don't think they're strictly necessary. That said, I do think I'd like to see the word "applications" occur sometime in the work items and the section on coordination. :-)

Can someone describe for me the difference between providing a set of "transport services" and providing a "session layer"? Does such a description need to go in here?

[Ballot comment]
This could go for external review as-is. Some things to consider, either now or during external review:

I am not as concerned about Benoit that these clarifications need to be made; they won't hurt, but I don't think they're strictly necessary. That said, I do think I'd like to see the word "applications" occur sometime in the work items and the section on coordination. :-)

Can someone describe for me the difference between providing a set of "transport services" and providing a "session layer"? Does such a description need to go in here?

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

[Ballot comment]
I am tempted to ask that it be made explicit that this be ipv6 only.

I think that's an important concession for recognizing the ipv4 internet has substantially ossified to the point that stack inovation that is  generally useful is confined being above transport.

likewise interactions that involve transition technologies should be off the table.

[Ballot comment]
I am tempted to ask that it be made explicit that this be ipv6 only.

I think that's an important concession for recognizing the ipv4 internet has substantially ossified to the point that stack inovation that is  generally useful is confined being above transport.

[Ballot comment]
I think this is ready for external review, but I have a question that I think should be addressed before this group gets chartered. There is no indication in the charter of the criteria that will be considered when selecting the subset of services that need to be supported by TAPS-capable endpoints. That seems to leave things quite open-ended and susceptible to arguments that most every service needs to be supported. If there is some existing notion that the subset will be tailored based on some criteria, it would be good to explain that in the charter.