Subject: [Taps] Comments on draft-ietf-taps-transports-03

From: Michael Welzl <[email-masked]>
Date: Sun, 22 Mar 2015 09:34:23 -0500

Hi,

Terribly sorry for looking at this so late! I just couldn't do it earlier. Also sorry for only "looking at it", not reading it in depth yet! Here are some early comments (I might have more after a deeper read):

Major:
- I do think that the terminology actually needs to clarify about what a "service" is. Following the chain of dependencies here, it is found in "Transport Service", where it says "... which provides a complete service to an application."

The reason I think we need to define this is that we should (IMO) explicitly exclude protocol functions that can improve the performance of the protocol *only* depending on environment characteristics but *irrespective* of the application. For example, things like ECN, SACK etc. shouldn't be regarded as a "service" in my opinion. As I'll say in my presentation tomorrow: for the work we previously did, we decided to ask, for every protocol component (adapted terminology here ;-) ):  "without knowledge about network conditions, would an application ever have a reason to say 'no' to this?"   => if the answer is "no", it's not a protocol component, because if it's purely a network optimization, it better be implemented in the protocol and not shown to the application. E.g., AFAIK the API of TCP does not allow the application to turn SACK on or off. That would be pointless, right?  => same logic here.

Why do I bring this up? Because I saw a few components that seem to me to fall in this category of "optimization depending on environment conditions but otherwise irrelevant for the application":
- IPv6 jumbograms in UDP. Though I don't know much about jumbograms, so I might be very wrong here.
 - timestamps in DCCP
- I didn't see ECN support mentioned elsewhere, but listed in the table in 4.1. I think it also falls in this category. 
- segmentation in TCP. Yes it's a part of what TCP does, but, repeating my question: "without knowledge about network conditions, would an application ever have a reason to say 'no' to this?" ... I think there's even one more reason to remove this: isn't this an inevitable element of stream-oriented data delivery (which is already listed)? Can you do this without segmentation?

UDP(-Lite) messes this up a bit... because it provides almost nothing and leaves all the job available to applications, hence an application running over UDP(-Lite) may need to be aware of almost everything, e.g. ECN capability. Maybe the right thing to do would be to treat UDP(-Lite) as a special case...

Minor:
- last para of intro: this talks about LEDBAT as if it was a protocol, not a congestion control mechanism.

- for better or worse, shouldn't "identification of urgent data" be a part of the protocol components of TCP?

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Mar 2015 09:34:59 -0700

On 3/22/2015 7:34 AM, Michael Welzl wrote:
> Major:
> - I do think that the terminology actually needs to clarify about
> what a "service" is. Following the chain of dependencies here, it is found in
> "Transport Service", where it says "... which provides a complete
> service to an application."
> 
> The reason I think we need to define this is that we should (IMO)
> explicitly exclude protocol functions that can improve the performance
> of the protocol *only* depending on environment characteristics but
> *irrespective* of the application. For example, things like ECN, SACK
> etc. shouldn't be regarded as a "service" in my opinion.

IMO, a "service" is a coherent whole. ECN, SACK, etc. are capabilities
within a service.

The difference is simple: a service is the smallest set of capabilities
that can be used independent of all others.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Mon, 23 Mar 2015 13:06:39 -0500

> On 23. mar. 2015, at 11.34, Joe Touch <[email-masked]> wrote:
> 
> 
> 

I completely agree and apologize, that was slopping writing on my side: I should have said "service component". Anyway my point was that ECN, SACK etc. shouldn't be any of that.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Mar 2015 11:11:18 -0700

On 3/23/2015 11:06 AM, Michael Welzl wrote:
> I completely agree and apologize, that was slopping writing on my
> side: I should have said "service component". Anyway my point was that
> ECN, SACK etc. shouldn't be any of that.

ECN and SACK are "how" a service achieves a capability, but they're not
capabilities.

Just like "Nagle" isn't a capability either.

These items are activated to achieve a capability. The closest for Nagle
would be "efficient transfer allowing delay".

YMMV, and I don't have a suggestion for the others.

Joe