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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
