On 3/23/2015 11:06 AM, Michael Welzl wrote: > >> On 23. mar. 2015, at 11.34, Joe Touch <[email protected]> wrote: >> >> >> >> 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. > > 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
