Re: [Taps] TCP components
Hi, Karen, On 7/16/2015 12:57 AM, Karen Elisabeth Egede Nielsen wrote: What portion of RFC793's API do you consider outdated? HI, I was thinking about the PUSH flag mainly. In our socket api implementation we do not allow for set of PUSH in send calls nor do we provide the PUSH flag indication upwards on the receiver side. That's consistent with RFC1122, which updates RFC793. I think that after RFC793 it has been clarified that TCP MAY allow for set of PUSH flag in send() and MAY OPTIONALLY provide this information upwards on the receiver side. Yes. I think that it would be questionable to follow RFC793 wording here on PUSH. Sure; I was being broad in my reference back to RFC793; updates need to be chased down too, so to the extent that the updates make RFC793 outdated, you're correct. However, the bulk of RFC793's API remains in effect. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 15 Jul 2015, at 11:03, Karen Elisabeth Egede Nielsen karen.niel...@tieto.com wrote: HI Mirja, All Sorry for jumping late into this discussion. -Original Message- From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Mirja Kühlewind Sent: Thursday, June 18, 2015 10:48 AM To: Joe Touch Cc: Brian Trammell; Michael Welzl; taps@ietf.org Subject: Re: [Taps] TCP components Hi Joe, I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs. The assumption is that someone who implemented/designed an API, thought that it would be worth to provide a configuration possibility to the higher layer. This assumption is more true for SCTP than for TCP because there are quite a few different TCP implementation that are grown over time. Quite often a new interface was only created because a new feature was added to TCP; and to be on the safe side we allow the user to turn it off again. That’s the reason why I prefer the approach we are/I'm taking right now (analyzing components). I think we should still describe the abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but I personally would not and will not spend too much time analyzing other API. [Karen ] I really do not think that it makes much sense to look into outdated and deprecated APIs as specified in RFC793 and RFC4960 when we have better material available. For SCTP here specifically RFC6458. Personally I cannot support this approach. I am not saying that we need very detailed APIs and therefore do not want RFC793 or RFC4960, but I want that what we do is based on the right specs (or the right defacto implementations) not on known-to-be outdated ones. I have been pointing at RFC6458 but was recently told (and I should have just read the thing instead of being told, sorry :-() that this RFC does not specify how SCTP's functions are supposed to be exposed to applications using them, but describes one example implementation (in great detail) instead. So, to identify the core functions of the protocol, RFC 4960 is probably a more appropriate source. I understand that it is difficult to find out exactly what is the fundament of TAPS - sometimes it is said that it is the existing IETF specifications - which means for example that SCTP-CMT and QUIC is outside of the scope. Then in other Taps communications - e.g. TCP components - it is said that one cannot fix the congestion control aspects of TCP as there I not one CC for TCP - and one do not know what people implements. I am not sure exactly what Taps should to do when the defacto standards (e.g. TCP) have superseded the actual standard. I think that it shall be on a best judgment basis and when there _are_ specs we should go with the most recent and sane ones and not with the outdated ones. One of the very first versions of our charter started the work off with a document that would lay out rules for us, as a basis to make such decisions. I venture to say that I was right to put this document there, and whoever recommended that I should remove it was wrong :-)because such a document would now be good to have, and I think it's easier to first try to agree on detailed rules (a more fine-grain charter, if you will - which protocols are in scope, how do we decide what a service is, etc.) than trying to immediately agree on the actual items themselves (SCTP-CMT: include it or not? Is the Nagle algorithm a service or not? etc.) Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 7/15/2015 2:03 AM, Karen Elisabeth Egede Nielsen wrote: HI Mirja, All Sorry for jumping late into this discussion. ... I really do not think that it makes much sense to look into outdated and deprecated APIs as specified in RFC793 and RFC4960 when we have better material available. What portion of RFC793's API do you consider outdated? AFAICT, it's exactly what most sockets try to support (I can't speak about SCTP, as I haven't used it much). Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 15 Jul 2015, at 12:40, Karen Elisabeth Egede Nielsen karen.niel...@tieto.com wrote: Hi Michael, All I have been pointing at RFC6458 but was recently told (and I should have just read the thing instead of being told, sorry :-() that this RFC does not specify how SCTP's functions are supposed to be exposed to applications using them, but describes one example implementation (in great detail) instead. So, to identify the core functions of the protocol, RFC 4960 is probably a more appropriate source. [Karen ] I both agree and disagree with this statement. My view on this is: If looking for an abstract interface I agree that many implementation details of RFC6458 are unnecessary. However a significant number of abstract functions are not described in RFC4960 and for control of/API for those one need to consult either RFC6458 - or for some of the functions - the api section of the RFCs defining these abstract functions. I would not know why one should consider only the core services of SCTP defined by RFC4960 as some significant protocol features are only defined by auxiliary RFCs. Further there are core features defined in RFC4960 for which - used (!) - control functions are only exposed in RFC6458. Okay, sigh :( not easy, is it? I don't like the API parts of RFC793 as it does not so well represent the API of the defacto TCP implementations - not the (very few) I know anyway. For example both the sender side and the receiver side handling of PUSH flag, which we seem to speak much about here, is not an example of a feature where the RFC793 description well represent the implementations. Also it obviously cannot well represent newer features, like e.g. control of ECN. Then, right, ECN may not make it as something we want to expose. Not sure. I think that RFC793 and RFC4960 may be good starting points, but saying that one will not look beyond them is a misunderstanding. In my view. I understand I understand that it is difficult to find out exactly what is the fundament of TAPS - sometimes it is said that it is the existing IETF specifications - which means for example that SCTP-CMT and QUIC is outside of the scope. Then in other Taps communications - e.g. TCP components - it is said that one cannot fix the congestion control aspects of TCP as there I not one CC for TCP - and one do not know what people implements. I am not sure exactly what Taps should to do when the defacto standards (e.g. TCP) have superseded the actual standard. I think that it shall be on a best judgment basis and when there _are_ specs we should go with the most recent and sane ones and not with the outdated ones. One of the very first versions of our charter started the work off with a document that would lay out rules for us, as a basis to make such decisions. I venture to say that I was right to put this document there, and whoever recommended that I should remove it was wrong :-)because such a document would now be good to have, and I think it's easier to first try to agree on detailed rules (a more fine-grain charter, if you will - which protocols are in scope, how do we decide what a service is, etc.) than trying to immediately agree on the actual items themselves (SCTP-CMT: include it or not? Is the Nagle algorithm a service or not? etc.) [Karen ] Yes. But learning by doing has merits as well. Perhaps one now has a more qualified view on what the rules should be. Agreed! Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
Hi Michael, All I have been pointing at RFC6458 but was recently told (and I should have just read the thing instead of being told, sorry :-() that this RFC does not specify how SCTP's functions are supposed to be exposed to applications using them, but describes one example implementation (in great detail) instead. So, to identify the core functions of the protocol, RFC 4960 is probably a more appropriate source. [Karen ] I both agree and disagree with this statement. My view on this is: If looking for an abstract interface I agree that many implementation details of RFC6458 are unnecessary. However a significant number of abstract functions are not described in RFC4960 and for control of/API for those one need to consult either RFC6458 - or for some of the functions - the api section of the RFCs defining these abstract functions. I would not know why one should consider only the core services of SCTP defined by RFC4960 as some significant protocol features are only defined by auxiliary RFCs. Further there are core features defined in RFC4960 for which - used (!) - control functions are only exposed in RFC6458. I don't like the API parts of RFC793 as it does not so well represent the API of the defacto TCP implementations - not the (very few) I know anyway. For example both the sender side and the receiver side handling of PUSH flag, which we seem to speak much about here, is not an example of a feature where the RFC793 description well represent the implementations. Also it obviously cannot well represent newer features, like e.g. control of ECN. Then, right, ECN may not make it as something we want to expose. Not sure. I think that RFC793 and RFC4960 may be good starting points, but saying that one will not look beyond them is a misunderstanding. In my view. I understand that it is difficult to find out exactly what is the fundament of TAPS - sometimes it is said that it is the existing IETF specifications - which means for example that SCTP-CMT and QUIC is outside of the scope. Then in other Taps communications - e.g. TCP components - it is said that one cannot fix the congestion control aspects of TCP as there I not one CC for TCP - and one do not know what people implements. I am not sure exactly what Taps should to do when the defacto standards (e.g. TCP) have superseded the actual standard. I think that it shall be on a best judgment basis and when there _are_ specs we should go with the most recent and sane ones and not with the outdated ones. One of the very first versions of our charter started the work off with a document that would lay out rules for us, as a basis to make such decisions. I venture to say that I was right to put this document there, and whoever recommended that I should remove it was wrong :-)because such a document would now be good to have, and I think it's easier to first try to agree on detailed rules (a more fine-grain charter, if you will - which protocols are in scope, how do we decide what a service is, etc.) than trying to immediately agree on the actual items themselves (SCTP-CMT: include it or not? Is the Nagle algorithm a service or not? etc.) [Karen ] Yes. But learning by doing has merits as well. Perhaps one now has a more qualified view on what the rules should be. BR, Karen Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
i dont have any spare time to do it, but maybe someone could have a go at analyzing all the different TCP offload techniques, which would give another lens to view this through... On Sat, Jun 20, 2015 at 9:35 AM, Michael Welzl mich...@ifi.uio.no wrote: On 20. jun. 2015, at 00.55, Joe Touch to...@isi.edu wrote: On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote: On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch to...@isi.edu mailto:to...@isi.edu wrote: You're getting far ahead of the conversation, IMO. This document needs to start by explaining the services we already have before jumping into a service of services model. I don't disagree with the goal, but it's impractical to develop a meta-interface when the base interface has not been described. It is just to say that TCP already defines its services, and the goal is not to give another definition of these services, but only to change the way they are exposed to applications. So the services definition already exists, but implicitly. It's explicit - see section 3.8 of RFC 793. The issue with that variant is that it captures the state of TCP in 1981; it has evolved quite a bit since then. Although we do have a 793-bis in the works, the update of that section hasn't been tackled yet. Let's put it this way: - if the goal of TAPS is to unify existing APIs, then those APIs need to be summarized together in one place - if TAPS is indeed focused solely on an alternate API, then it should NOT try to 'restate' the existing TCP API in a TAPS doc Do, or do not; there is no try. - Yoda TAPS is focused on an alternate API that it's based on existing transports. As a way of analyzing existing transports and creating a foundation for this API, document #1 is written. I think this discussion is about the approach taken to write document #1. So now I wonder what you're complaining about, as you go on about TCP already defining its services implicitly in the API. I mean, yes it does, okay - and so? You criticized the SCTP API for not being abstract enough - so clearly if we'd just copy+paste the API descriptions of the RFCs of the considered transports in a list, that would look pretty messy. You seem to want a clean approach, but you're not going to get that unless we focus on TCP alone :-) I've been proposing go through transport APIs and then analyze what we have, because this way, SCTP is already going to give us a long list of services. You've been saying that we should start with TCP. Well okay, but the service list there is pretty narrow. Maybe the TCP API isn't properly described in the current draft, okay, I think we can take that criticism for what it is. Still, I don't know what you're really after - in the end, we're going to get a list that's pretty similar to what's there now, and that's what we want, right? - unordered reliable delivery of messages - delivery of messages with timed delivery - reliable delivery of a data stream (naturally that's ordered) and so on. Right? Or what else is it you want / expect? Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 6/19/2015 6:55 PM, Joe Touch wrote: It's explicit - see section 3.8 of RFC 793. The issue with that variant is that it captures the state of TCP in 1981; it has evolved quite a bit since then. Although we do have a 793-bis in the works, the update of that section hasn't been tackled yet. I'm not sure that it will be tackled, but we should discuss that on the TCPM list :). Since there are no newer RFCs that alter, deprecate, or replace that API, I don't think we have a good basis to change it in 793bis. It's still pretty reasonable in my opinion. -- Wes Eddy MTI Systems ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 6/19/2015 2:39 PM, Mohamed Oulmahdi wrote: Of course, no one use a protocol without knowing the service it offers. When the application requests a TCP connection, it really request a reliable and ordered connection oriented service. The protocols primitives are used to each one to offer a part of this service. My point is that the API primitives do define the service offered in this case. You can't use TCP without using OPEN; OPEN exists only because TCP is connection-oriented. Similarly, SEND/RECEIVE are handled in-order and the byte order within each call is preserved - which indicates that this is a byte stream service. The lack of boundary marking within the SEND/RECEIVE calls - and the indication that SEND/RECEIVE block boundaries are not preserved - indicates that this is a byte stream service with no internal boundaries. All of this can be gleaned from the API in section 3.8 of RFC 793. The difficulty occurs when several protocols are available, with mainly a certain service overlapping. You're getting far ahead of the conversation, IMO. This document needs to start by explaining the services we already have before jumping into a service of services model. I don't disagree with the goal, but it's impractical to develop a meta-interface when the base interface has not been described. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote: On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch to...@isi.edu mailto:to...@isi.edu wrote: You're getting far ahead of the conversation, IMO. This document needs to start by explaining the services we already have before jumping into a service of services model. I don't disagree with the goal, but it's impractical to develop a meta-interface when the base interface has not been described. It is just to say that TCP already defines its services, and the goal is not to give another definition of these services, but only to change the way they are exposed to applications. So the services definition already exists, but implicitly. It's explicit - see section 3.8 of RFC 793. The issue with that variant is that it captures the state of TCP in 1981; it has evolved quite a bit since then. Although we do have a 793-bis in the works, the update of that section hasn't been tackled yet. Let's put it this way: - if the goal of TAPS is to unify existing APIs, then those APIs need to be summarized together in one place - if TAPS is indeed focused solely on an alternate API, then it should NOT try to 'restate' the existing TCP API in a TAPS doc Do, or do not; there is no try. - Yoda Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On Fri, Jun 19, 2015 at 6:15 PM, Joe Touch to...@isi.edu wrote: On 6/19/2015 6:22 AM, Michael Welzl wrote: On 19 Jun 2015, at 14:03, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: So there current API is always bound to a specify protocol which already provides you a certain set of service feature. At least in TCP there is not much choice left and there the current API does not give us a good indication which services are actually provided by TCP. Therefore from my point of view the only way to identify these services is to look at the protocol itself and not only the API. In SCTP it’s different and we definitely have to and will discuss the existing API in the document. Exactly that's why I thought starting with TCP's API (even when it's the abstract one) is not very helpful. Joe, Aaron: what is it you were expecting us to take away from reading section 3.8 of RFC 793? No. IMO, the current description of that API fails to indicate the controls *already* available to TCP. I don't agree that the TCP API doesn't indicate the service TCP provides - it's just implicit. E.g.: OPEN call indicates TCP is connection oriented SEND/RECEIVE calls indicates TCP is an ordered byte stream, that the user-level byte boundaries are NOT related to message boundaries, etc. Yes, there's some reading between the lines to do here. Of course, no one use a protocol without knowing the service it offers. When the application requests a TCP connection, it really request a reliable and ordered connection oriented service. The protocols primitives are used to each one to offer a part of this service. The difficulty occurs when several protocols are available, with mainly a certain service overlapping. In this case, exposing Transport services by the protocols offering them is not convenient to applications developers because they must be aware of the several protocols details that are not always evident to some of them. The objective is so simply to change this service exposition from a protocol-based to a service-based, allowing developers to request services without knowing anything about the underlying protocols offering these services. ( I can see it highlighting the need to discuss communication patterns (or decide for a specific one) in document #2, but not really contributing much to the list in document #1 ? ) I believe the opposite is true. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch to...@isi.edu wrote: You're getting far ahead of the conversation, IMO. This document needs to start by explaining the services we already have before jumping into a service of services model. I don't disagree with the goal, but it's impractical to develop a meta-interface when the base interface has not been described. It is just to say that TCP already defines its services, and the goal is not to give another definition of these services, but only to change the way they are exposed to applications. So the services definition already exists, but implicitly. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
hi Michael, A few replies inline. On 18 Jun 2015, at 15:54, Michael Welzl mich...@ifi.uio.no wrote: On 17 Jun 2015, at 12:13, Brian Trammell i...@trammell.ch wrote: hi Michael, all, A couple of random points inline at various levels of quotation... On 17 Jun 2015, at 10:44, Michael Welzl mich...@ifi.uio.no wrote: I agree that the list below is closer to what I think a component should be ... but looking at it, is it not even clearer now that components are not what TAPS is after? To me this list now contains lots and lots of details that are irrelevant to the service provided to the application. That's part of the point we're trying to address here. The realization we had here is that components *don't* necessarily map to feature, and it's not clear that we can simply ignore those components that don't map, since they may have impact on the interfaces/features it is possible to (reasonably) implement atop those protocols. Not harmful to list but pretty useless?! Let's start with TCP as probably the most difficult example (indeed, that's why we worked out this new arrangement of components for TCP first). A completely clean and unambiguous decomposition of TCP into its features -- what, I agree, we're after in the end -- is not *really* possible, because the protocols as defined and implemented weren't really composed of discrete features. The evolution of loss-based congestion control, for instance, was predicated on the particular loss signals that were available at the time it was first defined. The error detection mechanism likewise relies on the fact that reliability is provided by retransmission. One could say that given the parallel evolution of computing power that all these choices made by TCP were the only obvious ones at the time. But it's precisely the co-evolution of reliability and congestion control that makes gluing FEC to TCP so fraught with peril. That's an important point to capture IMO. I expect that the same exercise for SCTP will show a simpler mapping between components and features, since it *was* designed as a composition of features. I expect that too, but I still don't understand the point of the component list above. I mean, yes, you may be able to map and say we need components X Y Z to provide features A and B but how does this help TAPS? So as I see it, features are the TAPS view of the world of the future -- the set of things that transport protocols can do, and that a better interface can give you access to. Components are the view of the world of the present -- what the current definitions *and deployed implementations* of transport protocols can do, and what each of those features imply. There are a few ways you can implement the TAPS API. The one we chose to pursue in the WG (or at least I thought we had) is that the TAPS API takes (1) information from the application about its requirements in terms of features and parameters on those features (if available), (2) information from the path about which transport protocols and options are usable on the path, and the selects a transport protocol, and acts as glue between the API and the underlying protocol. In this approach, it is IMO important to catalog the protocol components (and the interactions among them) since the mappings between components and features might not be clean. This might not be the document to do that in. But we wanted to do the exercise to see what the outcome looked like. snip However, you could go for a even more generic approach and only look at the implementation and as a first step figure where are any knobs that in principle could be configurable and then afterwards discuss all of these very specific knobs. I though about this approach and think it would be an interest exercise and potentially the right way to go. But I also think that the overhead would be super large and I don’t think it would give us much more than we have right now. So we the current approach we might need to expect some arbitrariness… I lean towards this other one, of beginning with the knobs, ... understanding that interface definitions aren't just about which knobs (and indicators) the API provides, but also the interaction patterns it enables, and that these interaction patterns can also be made inefficient or even impractical by the details of the protocol in question. (It's always *possible* to implement object transfer over streams, or time domain transfer over objects, or to translate asynchonous events into a synchronous API. That the Web and video thereon work is proof of that. You can run the whole Internet over DNS, if you want to. It would not work as well as the one we have today. :) ) Yes, I agree, and I hope that this won't really bite us... or what's your plan for addressing this problem? In this document, I don't think we need to do anything. If we take an
Re: [Taps] TCP components
On 6/19/2015 7:15 AM, Mirja Kühlewind wrote: Cool! I think that the alternative approach Brian just proposed: Start with the feature we think/know we want to have and the compare them with what we have in the first document. -1 If you don't know what you already have, it's hard to figure out why what you need isn't there. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 6/19/2015 6:22 AM, Michael Welzl wrote: On 19 Jun 2015, at 14:03, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: So there current API is always bound to a specify protocol which already provides you a certain set of service feature. At least in TCP there is not much choice left and there the current API does not give us a good indication which services are actually provided by TCP. Therefore from my point of view the only way to identify these services is to look at the protocol itself and not only the API. In SCTP it’s different and we definitely have to and will discuss the existing API in the document. Exactly that's why I thought starting with TCP's API (even when it's the abstract one) is not very helpful. Joe, Aaron: what is it you were expecting us to take away from reading section 3.8 of RFC 793? No. IMO, the current description of that API fails to indicate the controls *already* available to TCP. I don't agree that the TCP API doesn't indicate the service TCP provides - it's just implicit. E.g.: OPEN call indicates TCP is connection oriented SEND/RECEIVE calls indicates TCP is an ordered byte stream, that the user-level byte boundaries are NOT related to message boundaries, etc. Yes, there's some reading between the lines to do here. ( I can see it highlighting the need to discuss communication patterns (or decide for a specific one) in document #2, but not really contributing much to the list in document #1 ? ) I believe the opposite is true. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 18 Jun 2015, at 10:48, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi Joe, I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs. No, wrong. Only abstract ones from RFCs, I said this before. These things would typically have preceding IETF debate, whereas trying to cover implementations is a huge and probably meaningless endeavour (the bar may be high for adding function calls to an API on system X and low for an API on system Y). The assumption is that someone who implemented/designed an API, thought that it would be worth to provide a configuration possibility to the higher layer. This assumption is more true for SCTP than for TCP because there are quite a few different TCP implementation that are grown over time. Quite often a new interface was only created because a new feature was added to TCP; and to be on the safe side we allow the user to turn it off again. That’s the reason why I prefer the approach we are/I'm taking right now (analyzing components). I think we should still describe the abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but I personally would not and will not spend too much time analyzing other API. However, everybody who has time and is interested in this can of course provide his/her outcome as input for this document and we will happily take it and compare it to what we have so far. But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), not implementations out there. More below, answering Joe (hm, that rhymes ;-) ) - Mirja Am 17.06.2015 um 20:10 schrieb Joe Touch to...@isi.edu: On 6/17/2015 1:44 AM, Michael Welzl wrote: I think that this discussion with Joe maybe suffered from focusing on TCP. To be fair, TCP has a simpler abstract API. SCTP is perhaps a better starting point because it supports almost everything. IMO, that makes it very hard as a starting point, and I also think that TCP's variant of an API description is much better as an example. E.g., Section 10 of RFC4960 claims it defines an abstract API (ULP-to_SCTP), but it begins by describing a call to initialize a data structure (INITIALIZE). That's decidedly NOT an abstract API; it's a generic description of an implementation issue. IMO, if we don't understand the difference between the API in RFC793 vs. that in RFC4960 (and why 793 is a better example), then this is going to be a very bumpy road. How abstract it is in the RFC indeed isn't my main concern here: it's to start with the interface (however abstract it is) offered to applications as described in the RFCs, as this reflects what the designers (with some level of IETF consensus) thought should be exposed. Now, of course SCTP has more options and is more complex in its usage than TCP, but it covers a larger part of the space of services in protocols - so I thought it's a good starting point, as in: 80% done by looking at 1 protocol, check the others for the remaining 20%. Something like that. This is just me being pragmatic and trying to have a more systematic approach to developing a list of services. I agree with Brian that some level of arbitrariness will always be there, but we must try to minimize it I think. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
Hi Michael, Am 18.06.2015 um 15:43 schrieb Michael Welzl mich...@ifi.uio.no: On 18 Jun 2015, at 10:48, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi Joe, I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs. No, wrong. Only abstract ones from RFCs, I said this before. These things would typically have preceding IETF debate, whereas trying to cover implementations is a huge and probably meaningless endeavour (the bar may be high for adding function calls to an API on system X and low for an API on system Y). Okay, but then I don’t really understand your approach fully. Yes we should document and look at what’s already specified in RFC, however isn’t the goal of taps to actually figure out how to change/extend/improve these APIs? How can we figure out what’s missing/wrong if we only look at what’s already there? Mirja The assumption is that someone who implemented/designed an API, thought that it would be worth to provide a configuration possibility to the higher layer. This assumption is more true for SCTP than for TCP because there are quite a few different TCP implementation that are grown over time. Quite often a new interface was only created because a new feature was added to TCP; and to be on the safe side we allow the user to turn it off again. That’s the reason why I prefer the approach we are/I'm taking right now (analyzing components). I think we should still describe the abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but I personally would not and will not spend too much time analyzing other API. However, everybody who has time and is interested in this can of course provide his/her outcome as input for this document and we will happily take it and compare it to what we have so far. But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), not implementations out there. More below, answering Joe (hm, that rhymes ;-) ) - Mirja Am 17.06.2015 um 20:10 schrieb Joe Touch to...@isi.edu: On 6/17/2015 1:44 AM, Michael Welzl wrote: I think that this discussion with Joe maybe suffered from focusing on TCP. To be fair, TCP has a simpler abstract API. SCTP is perhaps a better starting point because it supports almost everything. IMO, that makes it very hard as a starting point, and I also think that TCP's variant of an API description is much better as an example. E.g., Section 10 of RFC4960 claims it defines an abstract API (ULP-to_SCTP), but it begins by describing a call to initialize a data structure (INITIALIZE). That's decidedly NOT an abstract API; it's a generic description of an implementation issue. IMO, if we don't understand the difference between the API in RFC793 vs. that in RFC4960 (and why 793 is a better example), then this is going to be a very bumpy road. How abstract it is in the RFC indeed isn't my main concern here: it's to start with the interface (however abstract it is) offered to applications as described in the RFCs, as this reflects what the designers (with some level of IETF consensus) thought should be exposed. Now, of course SCTP has more options and is more complex in its usage than TCP, but it covers a larger part of the space of services in protocols - so I thought it's a good starting point, as in: 80% done by looking at 1 protocol, check the others for the remaining 20%. Something like that. This is just me being pragmatic and trying to have a more systematic approach to developing a list of services. I agree with Brian that some level of arbitrariness will always be there, but we must try to minimize it I think. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
On 17 Jun 2015, at 12:13, Brian Trammell i...@trammell.ch wrote: hi Michael, all, A couple of random points inline at various levels of quotation... On 17 Jun 2015, at 10:44, Michael Welzl mich...@ifi.uio.no wrote: On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi Michael, see below. Am 17.06.2015 um 09:36 schrieb Michael Welzl mich...@ifi.uio.no: Hi, On 11 Jun 2015, at 13:52, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi all, we gave it a first try to rewrite the component section for TCP. The insight I took from the discussion on the list is that components probably are much more linked to the implementation (choices) a certain protocol made while features are probably more high-level having the question in mind what does an application potentially want/need to know. So for the components in TCP we now have the following list: - Connection-oriented bidirectional communication using three-way handshake connection setup with feature negotiation and an explicit distinction between passive and active open: This implies both unicast addressing and a guarantee of return routability. - Single stream-oriented transmission: The stream abstraction atop the datagram service provided by IP is implemented by dividing the stream into segments. - Limited control over segment transmission scheduling (Nagle's algorithm): This allows for delay minimization in interactive applications. - Port multiplexing, with application-to-port mapping during connection setup: Note that in the presence of network address and port translation (NAPT), TCP ports are in effect part of the endpoint address for forwarding purposes. - Full reliability based on ack-based loss detection and retransmission: Loss is sensed using duplicated acks (fast retransmit), which places a lower bound on the delay inherent in this approach to reliability. - Error detection based on a checksum covering the network and transport headers as well as payload: Packets that are detected as corrupted are dropped, relying on the reliability mechanism to retransmit them. - Window-based flow control, with receiver-side window management and signaling of available window: Scaling the flow control window beyond 64kB requires the use of an optional feature, which has performance implications in environments where this option is not supported. - Window-based congestion control reacting to loss, delay, retransmission timeout, or an explicit congestion signal (ECN): Most commonly used is a loss signal from the reliability component's retransmission mechanism. TCP reacts to a congestion signal by reducing the size of the congestion window; retransmission timeout is generally handled with a larger reaction than other signals. We are currently still working on the list of features that results from thiese components but we are not there yet. Probably we not only need the features itself but also properties/aspects (or however you want to call this) of the feature. We already had this discussion a bit but wanted to postpone the decision if we really need to define an own term for this until we are sure that we need it. We are posting this list of (TCP) components now because we would like to get some feedback if this goes into the right direction/is on the right level of detail before we go on and apply this also to other protocols. I agree that the list below is closer to what I think a component should be ... but looking at it, is it not even clearer now that components are not what TAPS is after? To me this list now contains lots and lots of details that are irrelevant to the service provided to the application. That's part of the point we're trying to address here. The realization we had here is that components *don't* necessarily map to feature, and it's not clear that we can simply ignore those components that don't map, since they may have impact on the interfaces/features it is possible to (reasonably) implement atop those protocols. Not harmful to list but pretty useless?! Let's start with TCP as probably the most difficult example (indeed, that's why we worked out this new arrangement of components for TCP first). A completely clean and unambiguous decomposition of TCP into its features -- what, I agree, we're after in the end -- is not *really* possible, because the protocols as defined and implemented weren't really composed of discrete features. The evolution of loss-based congestion control, for instance, was predicated on the particular loss signals that were available at the time it was first defined. The error detection mechanism likewise relies on the fact that reliability is provided by retransmission. One could say that given the parallel evolution of computing power that all these choices made by TCP
Re: [Taps] TCP components
On 18. jun. 2015, at 15.56, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi Michael, Am 18.06.2015 um 15:43 schrieb Michael Welzl mich...@ifi.uio.no: On 18 Jun 2015, at 10:48, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi Joe, I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs. No, wrong. Only abstract ones from RFCs, I said this before. These things would typically have preceding IETF debate, whereas trying to cover implementations is a huge and probably meaningless endeavour (the bar may be high for adding function calls to an API on system X and low for an API on system Y). Okay, but then I don’t really understand your approach fully. Yes we should document and look at what’s already specified in RFC, however isn’t the goal of taps to actually figure out how to change/extend/improve these APIs? How can we figure out what’s missing/wrong if we only look at what’s already there? *My* goal is, and has always been, to provide a simpler, general API that is protocol independent. Note that this is not only for simplicity for ease of use BUT also for the sake of being able to automatize. After all the major goal is to remove the strict binding between applications and a specific protocol choice. To be able to do this (documents 2 and 3), we first need a list of the existing services - our toolbox, if you wish (document 1). Figuring out what's missing / wrong about today's APIs (except that they are bound to a specific protocol) has never been *my* major intention, and I certainly don't see that as the goal of this document. I'd be surprised if that's what the charter suggests?! But of course my opinion is only what it is, the charter reflects the consensus... All this being said, it can be a nice side-effect of the document (and note that noone knows what a TAPS system will really look like, and how these RFCs will actually end up being used). So I'm not strongly opposing the approach you're now following in that I don't see a big issue with there being a list of components - I just think it's not particularly useful for the goal of the document and doesn't really help the group progress towards its goals. I thought that proposing something more systematic with less arbitrariness could make it easier to put everyone in the same boat (in a way: look, the boat HAS to be like that, there wasn't much choice, sit down please rather than sorry I painted it green, I like that color; I can understand you would have preferred a blue boat...). Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
+1 On 6/18/2015 9:44 AM, Michael Welzl wrote: *My* goal is, and has always been, to provide a simpler, general API that is protocol independent. Note that this is not only for simplicity for ease of use BUT also for the sake of being able to automatize. After all the major goal is to remove the strict binding between applications and a specific protocol choice. To be able to do this (documents 2 and 3), we first need a list of the existing services - our toolbox, if you wish (document 1). Figuring out what's missing / wrong about today's APIs (except that they are bound to a specific protocol) has never been*my* major intention, and I certainly don't see that as the goal of this document. I'd be surprised if that's what the charter suggests?! But of course my opinion is only what it is, the charter reflects the consensus... ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] TCP components
Hi Michael, see below. Am 17.06.2015 um 09:36 schrieb Michael Welzl mich...@ifi.uio.no: Hi, On 11 Jun 2015, at 13:52, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi all, we gave it a first try to rewrite the component section for TCP. The insight I took from the discussion on the list is that components probably are much more linked to the implementation (choices) a certain protocol made while features are probably more high-level having the question in mind what does an application potentially want/need to know. So for the components in TCP we now have the following list: - Connection-oriented bidirectional communication using three-way handshake connection setup with feature negotiation and an explicit distinction between passive and active open: This implies both unicast addressing and a guarantee of return routability. - Single stream-oriented transmission: The stream abstraction atop the datagram service provided by IP is implemented by dividing the stream into segments. - Limited control over segment transmission scheduling (Nagle's algorithm): This allows for delay minimization in interactive applications. - Port multiplexing, with application-to-port mapping during connection setup: Note that in the presence of network address and port translation (NAPT), TCP ports are in effect part of the endpoint address for forwarding purposes. - Full reliability based on ack-based loss detection and retransmission: Loss is sensed using duplicated acks (fast retransmit), which places a lower bound on the delay inherent in this approach to reliability. - Error detection based on a checksum covering the network and transport headers as well as payload: Packets that are detected as corrupted are dropped, relying on the reliability mechanism to retransmit them. - Window-based flow control, with receiver-side window management and signaling of available window: Scaling the flow control window beyond 64kB requires the use of an optional feature, which has performance implications in environments where this option is not supported. - Window-based congestion control reacting to loss, delay, retransmission timeout, or an explicit congestion signal (ECN): Most commonly used is a loss signal from the reliability component's retransmission mechanism. TCP reacts to a congestion signal by reducing the size of the congestion window; retransmission timeout is generally handled with a larger reaction than other signals. We are currently still working on the list of features that results from thiese components but we are not there yet. Probably we not only need the features itself but also properties/aspects (or however you want to call this) of the feature. We already had this discussion a bit but wanted to postpone the decision if we really need to define an own term for this until we are sure that we need it. We are posting this list of (TCP) components now because we would like to get some feedback if this goes into the right direction/is on the right level of detail before we go on and apply this also to other protocols. I agree that the list below is closer to what I think a component should be ... but looking at it, is it not even clearer now that components are not what TAPS is after? To me this list now contains lots and lots of details that are irrelevant to the service provided to the application. Not harmful to list but pretty useless?! In this case we decided to list/discuss rather some more details, so that people can understand what we had in mind. We might remove some of these details/explanations at the end (or move those parts that are actually relevant into the feature section (4)). And how do you draw the line for what goes in and out of such a list? E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK are not mentioned? We tried to ask ourself which parts have an effect on the behavior of the flow that could potentially be of interest for the application. We might have missed some points. Actually Gorry already point out some. The next step is to work on the feature list and figure out how these things that are interesting for the application would be described in a more general way (independent of the concrete algorithm that is used by one protocol) and also discuss which features actually should be exposed because they have a real use for the application. To me, this whole thing is just too full of arbitrariness. We should aim for a systematic approach that minimizes the number of arbitrary decisions made IMO. For us the systematic approach is to look at the implementation of existing protocol an figure out which algorithm have an influence on the traffic that might be interest for a higher layer to control. So we always had, to some extend, the
Re: [Taps] TCP components
Another major item to add to the list would be: - MTU/MSS negotiation and management, including initial negotiation, response to packet-too-big signals from middle-boxes, and optional probing. To what degree is it worth talking about known design limitations and issues associated with each? For example, checksums in TCP not being large enough to detect errors in many high-volume real-world scenarios? Erik On Jun 11, 2015 7:53 AM, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi all, we gave it a first try to rewrite the component section for TCP. The insight I took from the discussion on the list is that components probably are much more linked to the implementation (choices) a certain protocol made while features are probably more high-level having the question in mind what does an application potentially want/need to know. So for the components in TCP we now have the following list: - Connection-oriented bidirectional communication using three-way handshake connection setup with feature negotiation and an explicit distinction between passive and active open: This implies both unicast addressing and a guarantee of return routability. - Single stream-oriented transmission: The stream abstraction atop the datagram service provided by IP is implemented by dividing the stream into segments. - Limited control over segment transmission scheduling (Nagle's algorithm): This allows for delay minimization in interactive applications. - Port multiplexing, with application-to-port mapping during connection setup: Note that in the presence of network address and port translation (NAPT), TCP ports are in effect part of the endpoint address for forwarding purposes. - Full reliability based on ack-based loss detection and retransmission: Loss is sensed using duplicated acks (fast retransmit), which places a lower bound on the delay inherent in this approach to reliability. - Error detection based on a checksum covering the network and transport headers as well as payload: Packets that are detected as corrupted are dropped, relying on the reliability mechanism to retransmit them. - Window-based flow control, with receiver-side window management and signaling of available window: Scaling the flow control window beyond 64kB requires the use of an optional feature, which has performance implications in environments where this option is not supported. - Window-based congestion control reacting to loss, delay, retransmission timeout, or an explicit congestion signal (ECN): Most commonly used is a loss signal from the reliability component's retransmission mechanism. TCP reacts to a congestion signal by reducing the size of the congestion window; retransmission timeout is generally handled with a larger reaction than other signals. We are currently still working on the list of features that results from thiese components but we are not there yet. Probably we not only need the features itself but also properties/aspects (or however you want to call this) of the feature. We already had this discussion a bit but wanted to postpone the decision if we really need to define an own term for this until we are sure that we need it. We are posting this list of (TCP) components now because we would like to get some feedback if this goes into the right direction/is on the right level of detail before we go on and apply this also to other protocols. Brian and Mirja ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
[Taps] TCP components
Hi all, we gave it a first try to rewrite the component section for TCP. The insight I took from the discussion on the list is that components probably are much more linked to the implementation (choices) a certain protocol made while features are probably more high-level having the question in mind what does an application potentially want/need to know. So for the components in TCP we now have the following list: - Connection-oriented bidirectional communication using three-way handshake connection setup with feature negotiation and an explicit distinction between passive and active open: This implies both unicast addressing and a guarantee of return routability. - Single stream-oriented transmission: The stream abstraction atop the datagram service provided by IP is implemented by dividing the stream into segments. - Limited control over segment transmission scheduling (Nagle's algorithm): This allows for delay minimization in interactive applications. - Port multiplexing, with application-to-port mapping during connection setup: Note that in the presence of network address and port translation (NAPT), TCP ports are in effect part of the endpoint address for forwarding purposes. - Full reliability based on ack-based loss detection and retransmission: Loss is sensed using duplicated acks (fast retransmit), which places a lower bound on the delay inherent in this approach to reliability. - Error detection based on a checksum covering the network and transport headers as well as payload: Packets that are detected as corrupted are dropped, relying on the reliability mechanism to retransmit them. - Window-based flow control, with receiver-side window management and signaling of available window: Scaling the flow control window beyond 64kB requires the use of an optional feature, which has performance implications in environments where this option is not supported. - Window-based congestion control reacting to loss, delay, retransmission timeout, or an explicit congestion signal (ECN): Most commonly used is a loss signal from the reliability component's retransmission mechanism. TCP reacts to a congestion signal by reducing the size of the congestion window; retransmission timeout is generally handled with a larger reaction than other signals. We are currently still working on the list of features that results from thiese components but we are not there yet. Probably we not only need the features itself but also properties/aspects (or however you want to call this) of the feature. We already had this discussion a bit but wanted to postpone the decision if we really need to define an own term for this until we are sure that we need it. We are posting this list of (TCP) components now because we would like to get some feedback if this goes into the right direction/is on the right level of detail before we go on and apply this also to other protocols. Brian and Mirja ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
