Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Greetings, all, We've submitted revision -04 of taps-transports, which includes: (1) a new section on HTTP as a pseudotransport over TCP (thanks, Dragana Damjanovic!) (2) a new section on NORM (thanks, Brian Adamson!) (3) frontmatter in Section 4 normalizing and categorizing the transport protocol components; please review this and suggest necessary or useful changes for using this as background for selecting taps features. Next up is completing the outstanding sections on transports and transport-like things, of which we have four: 3.2 MP-TCP 3.7 RTP 3.9 TLS/DTLS pseudotransport 3.11 WebSockets We hope to get an -05 with text for these out in the next couple of weeks, and will follow up with contributors for each of these sections shortly. Thanks, cheers, Brian (for the editors of taps-transports) > On 26 May 2015, at 14:41, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Services Working Group of the IETF. > >Title : Services provided by IETF transport protocols and > congestion control mechanisms >Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename: draft-ietf-taps-transports-04.txt > Pages : 35 > Date: 2015-05-26 > > Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps signature.asc Description: Message signed with OpenPGP using GPGMail ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hi, Brian (et al.), On 5/26/2015 6:25 AM, Brian Trammell wrote: ... > (3) frontmatter in Section 4 normalizing and categorizing the > transport protocol components; please review this and suggest necessary > or useful changes for using this as background for selecting taps features. I like the definitions but IMO the protocol descriptions don't follow the definitions. I.e., I agree that a transport protocol service (TPS) is a feature or capability made available to the app, and that a transport protocol component (TPC) is an implementation of such a feature. I realize I sound like a broken record, but the descriptions of the protocols herein still does not match the definition of TPS or TPC. E.g., for TCP, none of the following is exposed to the user: - segmentation - flow control - congestion control - error detection At best, the effects of the above are exposed to the user in very indirect fashion, certainly not as a "service" that can be used. In addition, TCP provides all of the following services (the latter two depending on being supported), which are not listed: - PUSH - URG - authentication (via TCP-AO or legacy TCP MD5) - control over user timeout (UTO option) This continues to be a pervasive issue in this doc, i.e., not just for this protocol. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hi Joe, I agree. This is a working document and we are still in the phase of collecting data while the next step is to discuss which things that are currently listed must/should be listed or not and also which of the things must/should be exposed to the app. However, I think we are on the write track for the TSC because these are thing that are implemented independent of the question if these things should be exposed to the app or not. However, features in contrast should really only be the things that should be exposed. The list in section 4 currently copies everything from above and we need to have the discuss now what should stay there and what not. Mirja > Am 27.05.2015 um 00:36 schrieb Joe Touch : > > Hi, Brian (et al.), > > On 5/26/2015 6:25 AM, Brian Trammell wrote: > ... >> (3) frontmatter in Section 4 normalizing and categorizing the >> transport protocol components; please review this and suggest necessary >> or useful changes for using this as background for selecting taps features. > > I like the definitions but IMO the protocol descriptions don't follow > the definitions. > > I.e., I agree that a transport protocol service (TPS) is a feature or > capability made available to the app, and that a transport protocol > component (TPC) is an implementation of such a feature. > > I realize I sound like a broken record, but the descriptions of the > protocols herein still does not match the definition of TPS or TPC. > > E.g., for TCP, none of the following is exposed to the user: > - segmentation > - flow control > - congestion control > - error detection > At best, the effects of the above are exposed to the user in very > indirect fashion, certainly not as a "service" that can be used. > > In addition, TCP provides all of the following services (the latter two > depending on being supported), which are not listed: > - PUSH > - URG > - authentication (via TCP-AO or legacy TCP MD5) > - control over user timeout (UTO option) > > This continues to be a pervasive issue in this doc, i.e., not just for > this protocol. > > 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] I-D Action: draft-ietf-taps-transports-04.txt
On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: > Hi Joe, > > I agree. This is a working document and we are still in the phase of > collecting data while the next step is to discuss which things that are > currently listed must/should be listed or not and also which of the > things must/should be exposed to the app. To be clear, can you clarify the focus?: - what IS/IS NOT (i.e., current requirements) - what WILL BE/WILL NOT BE (i.e., future goals) AFAICT, this is about IS/IS NOT. With that in mind, it should not be necessary to "collect data" and then decide later what is exposed or not. > However, I think we are on the write track for the TSC because these > are thing that are implemented independent of the question if these > things should be exposed to the app or not. There seems to be ample confusion about: - upper layer interface (abstract "API"): services to the user - lower layer interface: services needed from the next protocol layer - the protocol itself (as an abstract specification: i.e., the finite state machine rules that relate commands and responses to the ULI, calls and returns to the LLI, and internal state and events (e.g., timers) - the *implementation* of any of the above, e.g.: - Unix sockets API - interface to IPv4 - Differences that include Reno vs. Cubic..., MTU algs, etc. > However, features in > contrast should really only be the things that should be exposed. IMO, implementation issues should be fully out of scope. > The > list in section 4 currently copies everything from above and we need to > have the discuss now what should stay there and what not. Frankly, RFC 793 specified exactly what is needed here (it may need to be augmented with options and later extensions), but that needs to be a *starting point* for these discussions. And the current doc doesn't come close to what's in 793. If we're not starting there, there's little point in starting IMO. Joe > Mirja > > >> Am 27.05.2015 um 00:36 schrieb Joe Touch : >> >> Hi, Brian (et al.), >> >> On 5/26/2015 6:25 AM, Brian Trammell wrote: >> ... >>> (3) frontmatter in Section 4 normalizing and categorizing the >>> transport protocol components; please review this and suggest necessary >>> or useful changes for using this as background for selecting taps features. >> >> I like the definitions but IMO the protocol descriptions don't follow >> the definitions. >> >> I.e., I agree that a transport protocol service (TPS) is a feature or >> capability made available to the app, and that a transport protocol >> component (TPC) is an implementation of such a feature. >> >> I realize I sound like a broken record, but the descriptions of the >> protocols herein still does not match the definition of TPS or TPC. >> >> E.g., for TCP, none of the following is exposed to the user: >> - segmentation >> - flow control >> - congestion control >> - error detection >> At best, the effects of the above are exposed to the user in very >> indirect fashion, certainly not as a "service" that can be used. >> >> In addition, TCP provides all of the following services (the latter two >> depending on being supported), which are not listed: >> - PUSH >> - URG >> - authentication (via TCP-AO or legacy TCP MD5) >> - control over user timeout (UTO option) >> >> This continues to be a pervasive issue in this doc, i.e., not just for >> this protocol. >> >> 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] I-D Action: draft-ietf-taps-transports-04.txt
Hi Joe, see below... > Am 27.05.2015 um 19:20 schrieb Joe Touch : > > > On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: >> Hi Joe, >> >> I agree. This is a working document and we are still in the phase of >> collecting data while the next step is to discuss which things that are >> currently listed must/should be listed or not and also which of the >> things must/should be exposed to the app. > > To be clear, can you clarify the focus?: > > - what IS/IS NOT (i.e., current requirements) > > - what WILL BE/WILL NOT BE (i.e., future goals) > > AFAICT, this is about IS/IS NOT. With that in mind, it should not be > necessary to "collect data" and then decide later what is exposed or not. It’s about IS/IS NOT. However, currently there is very little (explicitly) exposed to the app. So the question is actually what should be exposed from the transport service components that are currently implemented in the then different existing transport protocols. > >> However, I think we are on the write track for the TSC because these >> are thing that are implemented independent of the question if these >> things should be exposed to the app or not. > > There seems to be ample confusion about: > > - upper layer interface (abstract "API"): services to the user > > - lower layer interface: services needed from the next protocol layer > > - the protocol itself (as an abstract specification: i.e., the finite > state machine rules that relate commands and responses to the ULI, calls > and returns to the LLI, and internal state and events (e.g., timers) > > - the *implementation* of any of the above, e.g.: > - Unix sockets API > - interface to IPv4 > - Differences that include Reno vs. Cubic..., MTU algs, etc. > >> However, features in >> contrast should really only be the things that should be exposed. > > IMO, implementation issues should be fully out of scope. It’s not about implementation issues but it’s not always absolutely clear which level of detail must be exposed to the app. Is it enough to only have an interface where you can choose to use congestion control or not, or do you need to choose between delay-based and lost-based congestion control, or foreground and background congestion control, or one specify algorithm, or just specify one specify detail of the algorithm e.g. don’t increase fast than one packet per RTT…? So the approach for the current document is to summarize what’s already there. We had some discussions about the level of detail of this document, and I believe we currently have a good compromise where we give some implementation details but also try to not make this document unnecessary long. > >> The >> list in section 4 currently copies everything from above and we need to >> have the discuss now what should stay there and what not. > > Frankly, RFC 793 specified exactly what is needed here (it may need to > be augmented with options and later extensions), but that needs to be a > *starting point* for these discussions. > > And the current doc doesn't come close to what's in 793. > > If we're not starting there, there's little point in starting IMO. 793 is the starting point. However this doc is not only on TCP. If you think that there important points missing, please propose new text or changes to the current text! Mirja > > Joe > > >> Mirja >> >> >>> Am 27.05.2015 um 00:36 schrieb Joe Touch : >>> >>> Hi, Brian (et al.), >>> >>> On 5/26/2015 6:25 AM, Brian Trammell wrote: >>> ... (3) frontmatter in Section 4 normalizing and categorizing the transport protocol components; please review this and suggest necessary or useful changes for using this as background for selecting taps features. >>> >>> I like the definitions but IMO the protocol descriptions don't follow >>> the definitions. >>> >>> I.e., I agree that a transport protocol service (TPS) is a feature or >>> capability made available to the app, and that a transport protocol >>> component (TPC) is an implementation of such a feature. >>> >>> I realize I sound like a broken record, but the descriptions of the >>> protocols herein still does not match the definition of TPS or TPC. >>> >>> E.g., for TCP, none of the following is exposed to the user: >>> - segmentation >>> - flow control >>> - congestion control >>> - error detection >>> At best, the effects of the above are exposed to the user in very >>> indirect fashion, certainly not as a "service" that can be used. >>> >>> In addition, TCP provides all of the following services (the latter two >>> depending on being supported), which are not listed: >>> - PUSH >>> - URG >>> - authentication (via TCP-AO or legacy TCP MD5) >>> - control over user timeout (UTO option) >>> >>> This continues to be a pervasive issue in this doc, i.e., not just for >>> this protocol. >>> >>> Joe >>> >>> ___ >>> Taps mailing list >>> Ta
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
hi Mirja, Joe, two more points inline... > On 28 May 2015, at 10:49, Mirja Kühlewind > wrote: > > Hi Joe, > > see below... > > >> Am 27.05.2015 um 19:20 schrieb Joe Touch : >> >> >> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: >>> Hi Joe, >>> >>> I agree. This is a working document and we are still in the phase of >>> collecting data while the next step is to discuss which things that are >>> currently listed must/should be listed or not and also which of the >>> things must/should be exposed to the app. >> >> To be clear, can you clarify the focus?: >> >> - what IS/IS NOT (i.e., current requirements) >> >> - what WILL BE/WILL NOT BE (i.e., future goals) >> >> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >> necessary to "collect data" and then decide later what is exposed or not. > > It’s about IS/IS NOT. However, currently there is very little (explicitly) > exposed to the app. > > So the question is actually what should be exposed from the transport service > components that are currently implemented in the then different existing > transport protocols. > >>> However, I think we are on the write track for the TSC because these >>> are thing that are implemented independent of the question if these >>> things should be exposed to the app or not. >> >> There seems to be ample confusion about: >> >> - upper layer interface (abstract "API"): services to the user >> >> - lower layer interface: services needed from the next protocol layer >> >> - the protocol itself (as an abstract specification: i.e., the finite >> state machine rules that relate commands and responses to the ULI, calls >> and returns to the LLI, and internal state and events (e.g., timers) >> >> - the *implementation* of any of the above, e.g.: >> - Unix sockets API >> - interface to IPv4 >> - Differences that include Reno vs. Cubic..., MTU algs, etc. >> >>> However, features in >>> contrast should really only be the things that should be exposed. >> >> IMO, implementation issues should be fully out of scope. I disagree that implementation- (and indeed, deployment-) level concerns are out of scope here. It's implementation level concerns which have made it necessary to do something like TAPS in the first place. In a world without middlebox impairment you don't need any path condition measurement or negotiation at all, and "transport flexibility" would simply be a matter of sticking libraries on top of TCP and/or SCTP options. > It’s not about implementation issues but it’s not always absolutely clear > which level of detail must be exposed to the app. Is it enough to only have > an interface where you can choose to use congestion control or not, or do you > need to choose between delay-based and lost-based congestion control, or > foreground and background congestion control, or one specify algorithm, or > just specify one specify detail of the algorithm e.g. don’t increase fast > than one packet per RTT…? There's a second issue here, as well, and it's kind of hiding behind the current structure of the document and the terminology. Right now, which transport protocol to use is either an explicit choice of the application developer (by selecting an API / library and set of configuration parameters which always map to a single wire protocol) or an implicit one (e.g. by selecting a library or higher-layer protocol on which to develop the application which only supports a single transport protocol). These protocols have positive properties (which we've called components) and negative properties (that is, use of this protocol excludes some other thing you might want to have). Stupid example: fully reliable single-streaming implies head-of-line blocking. Here the positive and negative properties are intrinsically linked. Less stupid example: assume you want reliable transport of messages but don't care at all about the order in which they arrive (e.g. because you're doing bulk object synchronization as with NORM). In this case reliability would be a positive property of TCP, and head-of-line blocking is a negative property, the positive counterpart of which (stream orientation) you don't even want. In this case, it is the choice of components pulled together into a single protocol at protocol design time which sets up the conflict. I'm not quite sure how to capture this, or indeed whether this document is where it should be captured, but it is very important for any approach to TAPS which will use off-the-shelf protocols. Cheers, Brian > So the approach for the current document is to summarize what’s already > there. We had some discussions about the level of detail of this document, > and I believe we currently have a good compromise where we give some > implementation details but also try to not make this document > unnecessary long. > >> >>> The >>> list in section 4 currently copies everything from above and we need to >>> ha
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
HI, I gave this comment also to version 03, but I will then repeat it here again :-): I do think that it is overkill to say that TCP implements the following Transport Protocol Components: o ordered delivery for each byte stream o stream-oriented delivery in a single stream Given that one TCP connection is able to serve one and only one byte stream, I think that it would suffice to give one of these statements. Preferably the latter one. BR, Karen >-Original Message- >From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Brian Trammell >Sent: Tuesday, May 26, 2015 3:26 PM >To: taps WG >Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt > >Greetings, all, > >We've submitted revision -04 of taps-transports, which includes: > >(1) a new section on HTTP as a pseudotransport over TCP (thanks, Dragana >Damjanovic!) > >(2) a new section on NORM (thanks, Brian Adamson!) > >(3) frontmatter in Section 4 normalizing and categorizing the transport >protocol components; please review this and suggest necessary or useful >changes for using this as background for selecting taps features. > >Next up is completing the outstanding sections on transports and transport- >like things, of which we have four: > >3.2 MP-TCP >3.7 RTP >3.9 TLS/DTLS pseudotransport >3.11 WebSockets > >We hope to get an -05 with text for these out in the next couple of weeks, >and will follow up with contributors for each of these sections shortly. > >Thanks, cheers, > >Brian (for the editors of taps-transports) > >> On 26 May 2015, at 14:41, internet-dra...@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> This draft is a work item of the Transport Services Working Group of the >IETF. >> >>Title : Services provided by IETF transport protocols and congestion >control mechanisms >>Authors : Godred Fairhurst >> Brian Trammell >> Mirja Kuehlewind >> Filename: draft-ietf-taps-transports-04.txt >> Pages : 35 >> Date: 2015-05-26 >> >> Abstract: >> This document describes services provided by existing IETF protocols >> and congestion control mechanisms. It is designed to help >> application and network stack programmers and to inform the work of >> the IETF TAPS Working Group. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-taps-transports-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> ___ >> 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] I-D Action: draft-ietf-taps-transports-04.txt
On 5/28/2015 1:49 AM, Mirja Kühlewind wrote: > Hi Joe, > > see below... > > >> Am 27.05.2015 um 19:20 schrieb Joe Touch : >> >> >> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: >>> Hi Joe, >>> >>> I agree. This is a working document and we are still in the phase of >>> collecting data while the next step is to discuss which things that are >>> currently listed must/should be listed or not and also which of the >>> things must/should be exposed to the app. >> >> To be clear, can you clarify the focus?: >> >> - what IS/IS NOT (i.e., current requirements) >> >> - what WILL BE/WILL NOT BE (i.e., future goals) >> >> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >> necessary to "collect data" and then decide later what is exposed or not. > > It’s about IS/IS NOT. However, currently there is very little (explicitly) > exposed to the app. That's contradictory. What IS/IS NOT exposed as per the specs is easy to determine. Anything not exposed is either not part of a spec or an incomplete implementation. Other stuff - like congestion control alg - is absolutely NOT part of any current TCP spec to expose to the API. > So the question is actually what should be exposed from the > transport service components that are currently implemented in the then > different > existing transport protocols. That's WILL BE, and a completely different issue IMO. If we don't clearly document the current requirements, it's very difficult to move forward with deciding how to extend that API. >>> However, I think we are on the write track for the TSC because these >>> are thing that are implemented independent of the question if these >>> things should be exposed to the app or not. >> >> There seems to be ample confusion about: >> >> - upper layer interface (abstract "API"): services to the user >> >> - lower layer interface: services needed from the next protocol layer >> >> - the protocol itself (as an abstract specification: i.e., the finite >> state machine rules that relate commands and responses to the ULI, calls >> and returns to the LLI, and internal state and events (e.g., timers) >> >> - the *implementation* of any of the above, e.g.: >> - Unix sockets API >> - interface to IPv4 >> - Differences that include Reno vs. Cubic..., MTU algs, etc. >> >>> However, features in >>> contrast should really only be the things that should be exposed. >> >> IMO, implementation issues should be fully out of scope. > > It’s not about implementation issues but it’s not always absolutely > clear which level of detail must be exposed to the app. It's absolutely clear in RFC 793 at least. > Is it enough to > only have an interface where you can choose to use congestion control or > not, That's not part of any current spec, so you're back to "tomorrowland" thinking. > or do you need to choose between delay-based and lost-based > congestion control, or foreground and background congestion control, or > one specify algorithm, or just specify one specify detail of the > algorithm e.g. don’t increase fast than one packet per RTT…? Potentially useful, but that's diving very deep into HOW TCP operates, rather than user-level issues. This is revisiting the old QOS debate: do you open the entire set of QOS parameters to the user, or merely provide the user with a set of user-visible goals and allow the protocol to decide how best to support them? In QOS, this ended up picking a very few types of service classes. The same goal might be useful here. But, again, that's a goal for the future. It's difficult to get there if there's no clear indication of the current APIs. > So the approach for the current document is to summarize what’s > already there. The doc needs to differentiate between "already required per specification" and "available in some implementations". The former sets the baseline. The latter is fodder for discussion of how to standardize API extensions. > We had some discussions about the level of detail of this > document, and I believe we currently have a good compromise where we > give some implementation details but also try to not make this document > unnecessary long. IMO, the problem is that there's no clear distinction between what's currently required vs. available in some instances. >>> The >>> list in section 4 currently copies everything from above and we need to >>> have the discuss now what should stay there and what not. >> >> Frankly, RFC 793 specified exactly what is needed here (it may need to >> be augmented with options and later extensions), but that needs to be a >> *starting point* for these discussions. >> >> And the current doc doesn't come close to what's in 793. >> >> If we're not starting there, there's little point in starting IMO. > > 793 is the starting point. However this doc is not only on TCP. I noted that I was listing the issues with 793 as an example. There are similar issues with the other transports. > If > you think that there im
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hi Joe, here is where the confusion comes from: this doc is not about APIs, it’s about transport services, or to say it even more concrete, transport services components and features. We do have a section on interfaces for each protocol but that just an add-on which might or might not be useful to have in this document, but the core of the document is to describe the components that are currently implemented independent of the current provided (app-layer) interface and then add some discuss of which of these components are useful to expose to the app as transport services feature (and which level of detail/degree of decision freedom for each feature). I know there have been many tries to do this. And I personally think we will not be able to get this right. However, I know that we can do better than what we have right now because that’s clearly broken. Mirja > Am 28.05.2015 um 19:35 schrieb Joe Touch : > > > > On 5/28/2015 1:49 AM, Mirja Kühlewind wrote: >> Hi Joe, >> >> see below... >> >> >>> Am 27.05.2015 um 19:20 schrieb Joe Touch : >>> >>> >>> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: Hi Joe, I agree. This is a working document and we are still in the phase of collecting data while the next step is to discuss which things that are currently listed must/should be listed or not and also which of the things must/should be exposed to the app. >>> >>> To be clear, can you clarify the focus?: >>> >>> - what IS/IS NOT (i.e., current requirements) >>> >>> - what WILL BE/WILL NOT BE (i.e., future goals) >>> >>> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >>> necessary to "collect data" and then decide later what is exposed or not. >> >> It’s about IS/IS NOT. However, currently there is very little (explicitly) >> exposed to the app. > > That's contradictory. > > What IS/IS NOT exposed as per the specs is easy to determine. > > Anything not exposed is either not part of a spec or an incomplete > implementation. Other stuff - like congestion control alg - is > absolutely NOT part of any current TCP spec to expose to the API. > >> So the question is actually what should be exposed from the >> transport service components that are currently implemented in the then >> different >> existing transport protocols. > > That's WILL BE, and a completely different issue IMO. If we don't > clearly document the current requirements, it's very difficult to move > forward with deciding how to extend that API. > However, I think we are on the write track for the TSC because these are thing that are implemented independent of the question if these things should be exposed to the app or not. >>> >>> There seems to be ample confusion about: >>> >>> - upper layer interface (abstract "API"): services to the user >>> >>> - lower layer interface: services needed from the next protocol layer >>> >>> - the protocol itself (as an abstract specification: i.e., the finite >>> state machine rules that relate commands and responses to the ULI, calls >>> and returns to the LLI, and internal state and events (e.g., timers) >>> >>> - the *implementation* of any of the above, e.g.: >>> - Unix sockets API >>> - interface to IPv4 >>> - Differences that include Reno vs. Cubic..., MTU algs, etc. >>> However, features in contrast should really only be the things that should be exposed. >>> >>> IMO, implementation issues should be fully out of scope. >> >> It’s not about implementation issues but it’s not always absolutely >> clear which level of detail must be exposed to the app. > > It's absolutely clear in RFC 793 at least. > >> Is it enough to >> only have an interface where you can choose to use congestion control or >> not, > > That's not part of any current spec, so you're back to "tomorrowland" > thinking. > >> or do you need to choose between delay-based and lost-based >> congestion control, or foreground and background congestion control, or >> one specify algorithm, or just specify one specify detail of the >> algorithm e.g. don’t increase fast than one packet per RTT…? > > Potentially useful, but that's diving very deep into HOW TCP operates, > rather than user-level issues. > > This is revisiting the old QOS debate: do you open the entire set of QOS > parameters to the user, or merely provide the user with a set of > user-visible goals and allow the protocol to decide how best to support > them? In QOS, this ended up picking a very few types of service classes. > The same goal might be useful here. > > But, again, that's a goal for the future. It's difficult to get there if > there's no clear indication of the current APIs. > >> So the approach for the current document is to summarize what’s >> already there. > > The doc needs to differentiate between "already required per > specification" and "available in some implementations". The former sets > the baseline. The latter is fodder for
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
On 5/28/2015 11:05 AM, Mirja Kühlewind wrote: > Hi Joe, > > here is where the confusion comes from: this doc is not about APIs, > it’s about transport services, or to say it even more concrete, > transport services components and features. Such services are either inherent to the transport (e.g., in-order, reliable delivery) or exposed as a control to the user (by the API). I.e., APIs are necessary but not sufficient to describe transport services. > We do have a section on > interfaces for each protocol but that just an add-on which might or > might not be useful to have in this document, but the core of the > document is to describe the components that are currently implemented > independent of the current provided (app-layer) interface and then add > some discuss of which of these components are useful to expose to the > app as transport services feature (and which level of detail/degree of > decision freedom for each feature). But then isn't it critical to also know what's already exposed, e.g., in the existing API? Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 28. mai 2015, at 20.18, Joe Touch wrote: > > > > On 5/28/2015 11:05 AM, Mirja Kühlewind wrote: >> Hi Joe, >> >> here is where the confusion comes from: this doc is not about APIs, >> it’s about transport services, or to say it even more concrete, >> transport services components and features. > > Such services are either inherent to the transport (e.g., in-order, > reliable delivery) or exposed as a control to the user (by the API). > > I.e., APIs are necessary but not sufficient to describe transport services. Agreed. Things that are in the APIs are what the document calls "transport service features", whereas what you here call "inherent services" is what the document calls "transport protocol components". I think it's a bit unfortunate that the API descriptions look very different in style from the list of components. Maybe a line could be drawn between: "transport service features" (components that are exposed to the application) ... and here come all the things found in today's (not tomorrow's!) APIs, as defined by the specs alone, not implementations and "transport protocol components" ... which is all the rest. I'm thinking of just a way of splitting the component lists, just to say "the following ones are exposed in the API today". >> We do have a section on >> interfaces for each protocol but that just an add-on which might or >> might not be useful to have in this document, but the core of the >> document is to describe the components that are currently implemented >> independent of the current provided (app-layer) interface and then add >> some discuss of which of these components are useful to expose to the >> app as transport services feature (and which level of detail/degree of >> decision freedom for each feature). > > But then isn't it critical to also know what's already exposed, e.g., in > the existing API? I think so - and the document tries to say that, by describing APIs. Doing it like I propose above could add clarity. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hi all, On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote: > >> here is where the confusion comes from: this doc is not about APIs, > >> it’s about transport services, or to say it even more concrete, > >> transport services components and features. > > Such services are either inherent to the transport (e.g., in-order, > > reliable delivery) or exposed as a control to the user (by the API). > > I.e., APIs are necessary but not sufficient to describe transport > > services. > Agreed. Things that are in the APIs are what the document calls > "transport service features", whereas what you here call "inherent > services" is what the document calls "transport protocol components". I am not sure I have the same understanding of what features are. More than what is exposed through the API (which indeed is very little in the majority of the cases), I think features is what the application implicitly expects when selecting a specific transport. I agree more about the components. The application however has no idea about the components. This is internal stuff within each protocol to provide the features (e.g., retransmission for reliability), or to be nice to the network (e.g., congestion control). I don't think the applications would care much for the latter (or maybe as a hindrance which limits how much of the capacity it can grab). At the moment, looking at the draft, I think that most “Transport Protocol Components” sections actually conflate features and components, and probably list more of the former than the latter. I don't think this is quite in line with the terminology: Transport Service Feature: : a specific end-to-end feature that a transport service provides to its clients. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc. Transport Protocol Component: : an implementation of a transport service feature within a protocol. For example for TCP, I would say that the following are features (that the application wants) - reliable delivery - ordered delivery for each byte stream - stream-oriented delivery in a single stream - unicast - data bundling (Nagle's algorithm) - port multiplexing while these are components (that the application doesn't see) - connection setup with feature negotiation and application-to-port mapping - error detection (checksum) - segmentation - flow control - congestion control > "transport service features" (components that are exposed to the > application) ... and here come all the things found in today's (not > tomorrow's!) APIs, as defined by the specs alone, not implementations > and "transport protocol components" ... which is all the rest. I'm > thinking of just a way of splitting the component lists, just to say > "the following ones are exposed in the API today". I think this makes sense. That said, beyond just the specs, I think it would be useful to consider what current implementations provide too, as this may offer a slightly different set of features which is, nonetheless, what developers of real applications are dealing with. -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. pgp8XLm_b9Hhm.pgp Description: PGP signature ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hi Oliver, I mostly agree with your understand, only minor points below. > Am 29.05.2015 um 10:05 schrieb Olivier Mehani : > > Hi all, > > On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote: here is where the confusion comes from: this doc is not about APIs, it’s about transport services, or to say it even more concrete, transport services components and features. >>> Such services are either inherent to the transport (e.g., in-order, >>> reliable delivery) or exposed as a control to the user (by the API). >>> I.e., APIs are necessary but not sufficient to describe transport >>> services. >> Agreed. Things that are in the APIs are what the document calls >> "transport service features", whereas what you here call "inherent >> services" is what the document calls "transport protocol components". > > I am not sure I have the same understanding of what features are. More > than what is exposed through the API (which indeed is very little in the > majority of the cases), I think features is what the application > implicitly expects when selecting a specific transport. Yes and no. So what you describe is the current state. A transport service is a set of transport services features and today you can select those features only implicitly by selection the transport protocol itself. However, I think that it is worth to provide an interface to configure each feature explicitly. Not completely sure yet that it is true. But for me that’s one of the goals of this working group to figure out if this statement is true. > > I agree more about the components. The application however has no idea > about the components. This is internal stuff within each protocol to > provide the features (e.g., retransmission for reliability), or to be > nice to the network (e.g., congestion control). I don't think the > applications would care much for the latter (or maybe as a hindrance > which limits how much of the capacity it can grab). > > At the moment, looking at the draft, I think that most “Transport > Protocol Components” sections actually conflate features and components, > and probably list more of the former than the latter. I don't think this > is quite in line with the terminology: > > Transport Service Feature: : a specific end-to-end feature that > a transport service provides to its clients. Examples include > confidentiality, reliable delivery, ordered delivery, > message-versus-stream orientation, etc. > > Transport Protocol Component: : an implementation of a transport > service feature within a protocol. > > For example for TCP, I would say that the following are features (that the > application wants) > - reliable delivery > - ordered delivery for each byte stream > - stream-oriented delivery in a single stream > - unicast > - data bundling (Nagle's algorithm) > - port multiplexing > while these are components (that the application doesn't see) > - connection setup with feature negotiation and application-to-port mapping > - error detection (checksum) > - segmentation > - flow control > - congestion control I also see this very slightly different. Features and components are for my understanding nothing exclusive. Each feature also has a corresponding component (but not the other way around). However, while the feature is ‚reliable delivery‘ (because that all the app cares about), the component might be more specific like "reliable delivery using accumulated ACKs and retransmissions’ as TCP does. The more important point is, that the current lists in the doc need work! Maybe some of the point you’ve listed above as features must be phrased more detailed to describe/list the actually component and then we need to decide which components actually also provide a feature (that should be exposed) and on which level this correlates to a feature. So the split you proposed above is a good starting point for this. > >> "transport service features" (components that are exposed to the >> application) ... and here come all the things found in today's (not >> tomorrow's!) APIs, as defined by the specs alone, not implementations >> and "transport protocol components" ... which is all the rest. I'm >> thinking of just a way of splitting the component lists, just to say >> "the following ones are exposed in the API today". > > I think this makes sense. That said, beyond just the specs, I think it > would be useful to consider what current implementations provide too, as > this may offer a slightly different set of features which is, > nonetheless, what developers of real applications are dealing with. You mean it term of APIs or component? Collecting information of components are are currently implemented/used is the purpose of this doc. Collecting information about API/config interfaces of what is implemented/used today is also useful but a rat-hole… therefore we try cover this aspect briefly in this doc but do not aim for comple
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 29 May 2015, at 10:27, Mirja Kühlewind > wrote: > > Hi Oliver, > > I mostly agree with your understand, only minor points below. > >> Am 29.05.2015 um 10:05 schrieb Olivier Mehani : >> >> Hi all, >> >> On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote: > here is where the confusion comes from: this doc is not about APIs, > it’s about transport services, or to say it even more concrete, > transport services components and features. Such services are either inherent to the transport (e.g., in-order, reliable delivery) or exposed as a control to the user (by the API). I.e., APIs are necessary but not sufficient to describe transport services. >>> Agreed. Things that are in the APIs are what the document calls >>> "transport service features", whereas what you here call "inherent >>> services" is what the document calls "transport protocol components". >> >> I am not sure I have the same understanding of what features are. More >> than what is exposed through the API (which indeed is very little in the >> majority of the cases), I think features is what the application >> implicitly expects when selecting a specific transport. > > Yes and no. So what you describe is the current state. A transport service is > a set of transport services features and today you can select those features > only implicitly by selection the transport protocol itself. > > However, I think that it is worth to provide an interface to configure each > feature explicitly. Not completely sure yet that it is true. But for me > that’s one of the goals of this working group to figure out if this statement > is true. > >> >> I agree more about the components. The application however has no idea >> about the components. This is internal stuff within each protocol to >> provide the features (e.g., retransmission for reliability), or to be >> nice to the network (e.g., congestion control). I don't think the >> applications would care much for the latter (or maybe as a hindrance >> which limits how much of the capacity it can grab). >> >> At the moment, looking at the draft, I think that most “Transport >> Protocol Components” sections actually conflate features and components, >> and probably list more of the former than the latter. I don't think this >> is quite in line with the terminology: >> >> Transport Service Feature: : a specific end-to-end feature that >> a transport service provides to its clients. Examples include >> confidentiality, reliable delivery, ordered delivery, >> message-versus-stream orientation, etc. >> >> Transport Protocol Component: : an implementation of a transport >> service feature within a protocol. >> >> For example for TCP, I would say that the following are features (that the >> application wants) >> - reliable delivery >> - ordered delivery for each byte stream >> - stream-oriented delivery in a single stream >> - unicast >> - data bundling (Nagle's algorithm) >> - port multiplexing >> while these are components (that the application doesn't see) >> - connection setup with feature negotiation and application-to-port mapping >> - error detection (checksum) >> - segmentation >> - flow control >> - congestion control > > I also see this very slightly different. Features and components are for my > understanding nothing exclusive. Each feature also has a corresponding > component (but not the other way around). However, while the feature is > ‚reliable delivery‘ (because that all the app cares about), the component > might be more specific like "reliable delivery using accumulated ACKs and > retransmissions’ as TCP does. > > The more important point is, that the current lists in the doc need work! > Maybe some of the point you’ve listed above as features must be phrased more > detailed to describe/list the actually component and then we need to decide > which components actually also provide a feature (that should be exposed) and > on which level this correlates to a feature. So the split you proposed above > is a good starting point for this. > > >> >>> "transport service features" (components that are exposed to the >>> application) ... and here come all the things found in today's (not >>> tomorrow's!) APIs, as defined by the specs alone, not implementations >>> and "transport protocol components" ... which is all the rest. I'm >>> thinking of just a way of splitting the component lists, just to say >>> "the following ones are exposed in the API today". >> >> I think this makes sense. That said, beyond just the specs, I think it >> would be useful to consider what current implementations provide too, as >> this may offer a slightly different set of features which is, >> nonetheless, what developers of real applications are dealing with. > > You mean it term of APIs or component? Collecting information of components > are are currently implemented/used is the purpose of this doc. Collecting
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
First, I think this discussion would benefit from a clarification of what "API" means, or at least to stop using that term in isolation. There are three distinct concepts: A- abstract protocol "upper layer interface" e.g., OPEN, CLOSE, ABORT, as per RFC 793 B- programmer API e.g., Linux C/C++ TCP socket interface C- instance of a programmer API e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface IMO, this document MUST discuss A, and can be address potential extensions to A based on examining variants of B and C. There are also the protocol features, which are the properties of the protocol that: - can be explicitly configured and monitored these are *exactly* A, B, and/or C above - can be implicitly detected some are based on the definition of the protocol, such as reliable, byte sequence delivery some are an artifact of the implementation, such as specific delays due to burst losses However, *none* of this is a rat-hole IF TAPS is intended to explain the service interface to the user. IMO, B and C above should be secondary considerations after A is clearly documented, but this draft is a long way from that. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 29. mai 2015, at 19.32, Joe Touch wrote: > > First, I think this discussion would benefit from a clarification of > what "API" means, or at least to stop using that term in isolation. > > There are three distinct concepts: > > A- abstract protocol "upper layer interface" > e.g., OPEN, CLOSE, ABORT, as per RFC 793 > > B- programmer API > e.g., Linux C/C++ TCP socket interface > > C- instance of a programmer API > e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface > > IMO, this document MUST discuss A, and can be address potential > extensions to A based on examining variants of B and C. > > There are also the protocol features, which are the properties of the > protocol that: > - can be explicitly configured and monitored > these are *exactly* A, B, and/or C above > > - can be implicitly detected > some are based on the definition of the protocol, > such as reliable, byte sequence delivery > > some are an artifact of the implementation, > such as specific delays due to burst losses > > However, *none* of this is a rat-hole IF TAPS is intended to explain the > service interface to the user. IMO, B and C above should be secondary > considerations after A is clearly documented, but this draft is a long > way from that. I agree: A should be there, and it should probably the primary focus, as starting with a list of A would add a lot of clarity to the document and the discussion of it. Some text on protocol internals, explaing what a protocol does even though these things may not be exposed to an application, can be valuable even if only to know which protocol to choose. So I'm not suggesting removing everything but I'd agree that the focus of the document should shift towards a list of A. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 28. mai 2015, at 11.08, Brian Trammell wrote: > > hi Mirja, Joe, > > two more points inline... > >> On 28 May 2015, at 10:49, Mirja Kühlewind >> wrote: >> >> Hi Joe, >> >> see below... >> >> >>> Am 27.05.2015 um 19:20 schrieb Joe Touch : >>> >>> >>> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: Hi Joe, I agree. This is a working document and we are still in the phase of collecting data while the next step is to discuss which things that are currently listed must/should be listed or not and also which of the things must/should be exposed to the app. >>> >>> To be clear, can you clarify the focus?: >>> >>> - what IS/IS NOT (i.e., current requirements) >>> >>> - what WILL BE/WILL NOT BE (i.e., future goals) >>> >>> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >>> necessary to "collect data" and then decide later what is exposed or not. >> >> It’s about IS/IS NOT. However, currently there is very little (explicitly) >> exposed to the app. >> >> So the question is actually what should be exposed from the transport >> service components that are currently implemented in the then different >> existing transport protocols. >> However, I think we are on the write track for the TSC because these are thing that are implemented independent of the question if these things should be exposed to the app or not. >>> >>> There seems to be ample confusion about: >>> >>> - upper layer interface (abstract "API"): services to the user >>> >>> - lower layer interface: services needed from the next protocol layer >>> >>> - the protocol itself (as an abstract specification: i.e., the finite >>> state machine rules that relate commands and responses to the ULI, calls >>> and returns to the LLI, and internal state and events (e.g., timers) >>> >>> - the *implementation* of any of the above, e.g.: >>> - Unix sockets API >>> - interface to IPv4 >>> - Differences that include Reno vs. Cubic..., MTU algs, etc. >>> However, features in contrast should really only be the things that should be exposed. >>> >>> IMO, implementation issues should be fully out of scope. > > I disagree that implementation- (and indeed, deployment-) level concerns are > out of scope here. It's implementation level concerns which have made it > necessary to do something like TAPS in the first place. In a world without > middlebox impairment you don't need any path condition measurement or > negotiation at all, and "transport flexibility" would simply be a matter of > sticking libraries on top of TCP and/or SCTP options. This sounds like you were talking cross purposes. My interpretation here is that Joe is saying (as in his other email) that "concept A" in his other email: http://www.ietf.org/mail-archive/web/taps/current/msg00490.html should be in scope of the discussion, but B and C should not. I agree with that and your answer doesn't say you don't. How to implement / deploy something are concerns that should be in scope of TAPS (they clearly are as per item 3 in its charter), but not necessarily in scope of this first document. >> It’s not about implementation issues but it’s not always absolutely clear >> which level of detail must be exposed to the app. Is it enough to only have >> an interface where you can choose to use congestion control or not, or do >> you need to choose between delay-based and lost-based congestion control, or >> foreground and background congestion control, or one specify algorithm, or >> just specify one specify detail of the algorithm e.g. don’t increase fast >> than one packet per RTT…? > > There's a second issue here, as well, and it's kind of hiding behind the > current structure of the document and the terminology. > > Right now, which transport protocol to use is either an explicit choice of > the application developer (by selecting an API / library and set of > configuration parameters which always map to a single wire protocol) or an > implicit one (e.g. by selecting a library or higher-layer protocol on which > to develop the application which only supports a single transport protocol). > > These protocols have positive properties (which we've called components) and > negative properties (that is, use of this protocol excludes some other thing > you might want to have). Stupid example: fully reliable single-streaming > implies head-of-line blocking. Here the positive and negative properties are > intrinsically linked. Less stupid example: assume you want reliable transport > of messages but don't care at all about the order in which they arrive (e.g. > because you're doing bulk object synchronization as with NORM). In this case > reliability would be a positive property of TCP, and head-of-line blocking is > a negative property, the positive counterpart of which (stream orientation) > you don't even want. In this case, it is the choice of components pulled
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hey Mirja, On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja Kühlewind wrote: > > I am not sure I have the same understanding of what features are. > > More than what is exposed through the API (which indeed is very > > little in the majority of the cases), I think features is what the > > application implicitly expects when selecting a specific transport. > Yes and no. So what you describe is the current state. A transport > service is a set of transport services features and today you can > select those features only implicitly by selection the transport > protocol itself. > However, I think that it is worth to provide an interface to configure > each feature explicitly. Not completely sure yet that it is true. But > for me that’s one of the goals of this working group to figure out if > this statement is true. Yes, that's how I understand it too. Nonetheless, we need to start with what we have: groups of features that we need to identify and separate. > > At the moment, looking at the draft, I think that most “Transport > > Protocol Components” sections actually conflate features and components, > > and probably list more of the former than the latter. I don't think this > > is quite in line with the terminology: [...] > > > > For example for TCP, I would say that the following are features (that the > > application wants) > > - reliable delivery > > - ordered delivery for each byte stream > > - stream-oriented delivery in a single stream > > - unicast > > - data bundling (Nagle's algorithm) > > - port multiplexing > > while these are components (that the application doesn't see) > > - connection setup with feature negotiation and application-to-port mapping > > - error detection (checksum) > > - segmentation > > - flow control > > - congestion control > I also see this very slightly different. Features and components are > for my understanding nothing exclusive. Each feature also has a > corresponding component (but not the other way around). However, while > the feature is ‚reliable delivery‘ (because that all the app cares > about), the component might be more specific like "reliable delivery > using accumulated ACKs and retransmissions’ as TCP does. Yes, I completely agree. But I think the difference you higlight is important: each feature has one (or more, I'd say) corresponding components, while components might not necessarily result in an application-visible feature. > The more important point is, that the current lists in the doc need > work! Maybe some of the point you’ve listed above as features must be > phrased more detailed to describe/list the actually component and then > we need to decide which components actually also provide a feature > (that should be exposed) and on which level this correlates to a > feature. So the split you proposed above is a good starting point for > this. I'm glad to read it (: > >> "transport service features" (components that are exposed to the > >> application) ... and here come all the things found in today's (not > >> tomorrow's!) APIs, as defined by the specs alone, not > >> implementations and "transport protocol components" ... which is > >> all the rest. I'm thinking of just a way of splitting the component > >> lists, just to say "the following ones are exposed in the API > >> today". > > I think this makes sense. That said, beyond just the specs, I think > > it would be useful to consider what current implementations provide > > too, as this may offer a slightly different set of features which > > is, nonetheless, what developers of real applications are dealing > > with. > You mean it term of APIs or component? Collecting information of > components are are currently implemented/used is the purpose of this > doc. Collecting information about API/config interfaces of what is > implemented/used today is also useful but a rat-hole… therefore we try > cover this aspect briefly in this doc but do not aim for completeness > here. Yes, this is likely for a later document. However, I think we should make sure that some transport API have not implemented some non-standardised behaviours that a non-negligible number of applications use. I am not sure it's the case, but if it is so, we probably want to take that onboard at some point too. -- Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. pgpocHjNVV0UF.pgp Description: PGP signature ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 1. jun. 2015, at 03.17, Olivier Mehani wrote: > > Hey Mirja, > > On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja Kühlewind wrote: >>> I am not sure I have the same understanding of what features are. >>> More than what is exposed through the API (which indeed is very >>> little in the majority of the cases), I think features is what the >>> application implicitly expects when selecting a specific transport. >> Yes and no. So what you describe is the current state. A transport >> service is a set of transport services features and today you can >> select those features only implicitly by selection the transport >> protocol itself. >> However, I think that it is worth to provide an interface to configure >> each feature explicitly. Not completely sure yet that it is true. But >> for me that’s one of the goals of this working group to figure out if >> this statement is true. > > Yes, that's how I understand it too. Nonetheless, we need to start with > what we have: groups of features that we need to identify and separate. > >>> At the moment, looking at the draft, I think that most “Transport >>> Protocol Components” sections actually conflate features and components, >>> and probably list more of the former than the latter. I don't think this >>> is quite in line with the terminology: > [...] >>> >>> For example for TCP, I would say that the following are features (that the >>> application wants) >>> - reliable delivery >>> - ordered delivery for each byte stream >>> - stream-oriented delivery in a single stream >>> - unicast >>> - data bundling (Nagle's algorithm) >>> - port multiplexing >>> while these are components (that the application doesn't see) >>> - connection setup with feature negotiation and application-to-port mapping >>> - error detection (checksum) >>> - segmentation >>> - flow control >>> - congestion control >> I also see this very slightly different. Features and components are >> for my understanding nothing exclusive. Each feature also has a >> corresponding component (but not the other way around). However, while >> the feature is ‚reliable delivery‘ (because that all the app cares >> about), the component might be more specific like "reliable delivery >> using accumulated ACKs and retransmissions’ as TCP does. > > Yes, I completely agree. But I think the difference you higlight is > important: each feature has one (or more, I'd say) corresponding > components, while components might not necessarily result in an > application-visible feature. > >> The more important point is, that the current lists in the doc need >> work! Maybe some of the point you’ve listed above as features must be >> phrased more detailed to describe/list the actually component and then >> we need to decide which components actually also provide a feature >> (that should be exposed) and on which level this correlates to a >> feature. So the split you proposed above is a good starting point for >> this. > > I'm glad to read it (: > "transport service features" (components that are exposed to the application) ... and here come all the things found in today's (not tomorrow's!) APIs, as defined by the specs alone, not implementations and "transport protocol components" ... which is all the rest. I'm thinking of just a way of splitting the component lists, just to say "the following ones are exposed in the API today". >>> I think this makes sense. That said, beyond just the specs, I think >>> it would be useful to consider what current implementations provide >>> too, as this may offer a slightly different set of features which >>> is, nonetheless, what developers of real applications are dealing >>> with. >> You mean it term of APIs or component? Collecting information of >> components are are currently implemented/used is the purpose of this >> doc. Collecting information about API/config interfaces of what is >> implemented/used today is also useful but a rat-hole… therefore we try >> cover this aspect briefly in this doc but do not aim for completeness >> here. > > Yes, this is likely for a later document. However, I think we should > make sure that some transport API have not implemented some > non-standardised behaviours that a non-negligible number of applications > use. I am not sure it's the case, but if it is so, we probably want to > take that onboard at some point too. I'd like to stress "at some point" (if at all). Maybe not even in this particular document? This is exactly the layering problem here - transport protocol designers will have thought through what kind of information should be exposed. App programmers are now facing today's systems that they need to optimize as good as they can. Maybe ad hoc decisions are / were made to allow some protocol tuning that shouldn't really be an application's problem. To me, apps fine tuning protocols in non-standard ways is already one small step in the direction of what TAPS is trying to help again
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hi Joe, hi Michael, I completely welcome to add more text to the Interface description section (3.1.2). Currently this section is very short and says regarding the (higher layer) interface described in FRC793: "A User/TCP Interface is defined in [RFC0793] providing six user commands: Open, Send, Receive, Close, Status. This interface does not describe configuration of TCP options or parameters beside use of the PUSH and URGENT flags.“ This text was already added based on Joe’s input. Please provide more text if you think this is not sufficient. Probably we should at least add one more sentence describing the TCP-to-User interface (as it is called in RFC 793) like this: „Further the TCP-to-User interface is described providing information on the local connection name, the response string, the send and received buffer addresses, the Byte count (which counts bytes received) as well as the PUSH flag and URGENT flag.“ However, from my point of view I actually think that these (basic) things do not need to be discussed in more detail because the described interface is completely okay and can probably be mostly say as it is. The more complicated question is which additional things are needed and, even more important, how can you design a transport interface where the application does not need to choose the protocol first. Because the interface in RFC 793 only describes a User/TCP interface where TCP already determines a certain transport service or a set of transport services features relating to specific transport components. The whole goal or taps is to make things more flexible which mean we need more information before we open a connection and probably also during the connection. One information could be „I want to use a TCP header“ and maybe together with these features… However, as soon as we have chosen certain protocol which might be TCP be still need Open, send, receive and closes commands as described in RFC 793. So what I want to say is, that the described interface in RFC 793 is so basic that it is not wrong and should be described in this doc (as it is) but it does help us very much to get to the goal we would like to reach in taps which I currently would describe as: Extend the application layer interface to consequently provide a more flexible transport layer. Or even better the other way around: Create a more flexible transport layer which most likely will lead to an extended application-level interface. Another thing I also would like to say (again) at this point is that the current doc will not specify an new interface. We on purpose ‚only‘ talk about transport components and features in this document because we first need to know what we want to do before we can talk about the interface. However, again, if you think there is something important missing in this doc, please send text! Currently we will (more or less) just integrate all text that we get because it is much easier to discuss about text that is there and something that is not there. That does also mean that any text that is currently in the doc can be discussed, changed or removed! Mirja > Am 30.05.2015 um 14:24 schrieb Michael Welzl : > > >> On 29. mai 2015, at 19.32, Joe Touch wrote: >> >> First, I think this discussion would benefit from a clarification of >> what "API" means, or at least to stop using that term in isolation. >> >> There are three distinct concepts: >> >> A- abstract protocol "upper layer interface" >> e.g., OPEN, CLOSE, ABORT, as per RFC 793 >> >> B- programmer API >> e.g., Linux C/C++ TCP socket interface >> >> C- instance of a programmer API >> e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface >> >> IMO, this document MUST discuss A, and can be address potential >> extensions to A based on examining variants of B and C. >> >> There are also the protocol features, which are the properties of the >> protocol that: >> - can be explicitly configured and monitored >> these are *exactly* A, B, and/or C above >> >> - can be implicitly detected >> some are based on the definition of the protocol, >> such as reliable, byte sequence delivery >> >> some are an artifact of the implementation, >> such as specific delays due to burst losses >> >> However, *none* of this is a rat-hole IF TAPS is intended to explain the >> service interface to the user. IMO, B and C above should be secondary >> considerations after A is clearly documented, but this draft is a long >> way from that. > > I agree: A should be there, and it should probably the primary focus, as > starting with a list of A would add a lot of clarity to the document and the > discussion of it. > > Some text on protocol internals, explaing what a protocol does even though > these things may not be exposed to an application, can be valuable even if > only to kn
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 1. jun. 2015, at 16.32, Mirja Kühlewind > wrote: > > Hi Joe, hi Michael, > > I completely welcome to add more text to the Interface description section > (3.1.2). Currently this section is very short and says regarding the (higher > layer) interface described in FRC793: > > "A User/TCP Interface is defined in [RFC0793] providing six user > commands: Open, Send, Receive, Close, Status. This interface does > not describe configuration of TCP options or parameters beside use of > the PUSH and URGENT flags.“ > > This text was already added based on Joe’s input. Please provide more text if > you think this is not sufficient. > > Probably we should at least add one more sentence describing the TCP-to-User > interface (as it is called in RFC 793) like this: > > „Further the TCP-to-User interface is described providing information on the > local connection name, the response string, the send and received buffer > addresses, the Byte count (which counts bytes received) as well as the PUSH > flag and URGENT flag.“ I agree > However, from my point of view I actually think that these (basic) things do > not need to be discussed in more detail because the described interface is > completely okay and can probably be mostly say as it is. I agree > The more complicated question is which additional things are needed and, even > more important, how can you design a transport interface where the > application does not need to choose the protocol first. Because the interface > in RFC 793 only describes a User/TCP interface where TCP already determines a > certain transport service or a set of transport services features relating to > specific transport components. The whole goal or taps is to make things more > flexible which mean we need more information before we open a connection and > probably also during the connection. True, but this sounds out of scope of this document? This is just supposed to list the services... > One information could be „I want to use a TCP header“ and maybe together with > these features… However, as soon as we have chosen certain protocol which > might be TCP be still need Open, send, receive and closes commands as > described in RFC 793. I'd say "I want to use a TCP header" should definitely be out of scope of all this because it defeats the purpose of the TAPS idea. If I know I want to use a TCP header, I don't use TAPS, I use TCP! We're not aiming at replacing the interface for all applications, just offering something new. > So what I want to say is, that the described interface in RFC 793 is so basic > that it is not wrong and should be described in this doc (as it is) but it > does help us very much to get to the goal we would like to reach in taps > which I currently would describe as: Extend the application layer interface > to consequently provide a more flexible transport layer. Or even better the > other way around: Create a more flexible transport layer which most likely > will lead to an extended application-level interface. Yes, but... > Another thing I also would like to say (again) at this point is that the > current doc will not specify an new interface. Exactly :-) > We on purpose ‚only‘ talk about transport components and features in this > document because we first need to know what we want to do before we can talk > about the interface. > > However, again, if you think there is something important missing in this > doc, please send text! > Currently we will (more or less) just integrate all text that we get because > it is much easier to discuss about text that is there and something that is > not there. That does also mean that any text that is currently in the doc can > be discussed, changed or removed! Good, thanks. Anyway my point was that, in this list of services, we should be clear about Joe's item A: what is currently offered to apps by the current specs. This is the most important part of the list because it reflects what designers of these protocols (and with them, some form of prior IETF group consensus) think should be offered to apps. Going beyond that by discussing internals or things that some apps now can tune is a nice extra perhaps, but I think it should be a secondary goal. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
On 6/1/2015 9:45 AM, Michael Welzl wrote: > >> On 1. jun. 2015, at 16.32, Mirja Kühlewind >> wrote: >> >> Hi Joe, hi Michael, >> >> I completely welcome to add more text to the Interface description section >> (3.1.2). Currently this section is very short and says regarding the (higher >> layer) interface described in FRC793: >> >> "A User/TCP Interface is defined in [RFC0793] providing six user >> commands: Open, Send, Receive, Close, Status. This interface does >> not describe configuration of TCP options or parameters beside use of >> the PUSH and URGENT flags.“ >> >> This text was already added based on Joe’s input. Please provide more text >> if you think this is not sufficient. >> >> Probably we should at least add one more sentence describing the TCP-to-User >> interface (as it is called in RFC 793) like this: >> >> „Further the TCP-to-User interface is described providing information on the >> local connection name, the response string, the send and received buffer >> addresses, the Byte count (which counts bytes received) as well as the PUSH >> flag and URGENT flag.“ > > I agree My concern is that there is no clear relation between 3.1.2 and 3.1.3. In fact, many of the properties of 3.1.3 are the result of the interface mentioned in 3.1.2. Also, a few aspects of the 3.1.2 interface aren't considered in 3.1.3. So what's the point of 3.1.3? >From the definition: Transport Protocol Component: an implementation of a transport service feature within a protocol. Unfortunately, the items in 3.1.3 aren't implementations; they're general properties. An implementation would be Reno or CUBIC. In addition, API isn't defined (e.g., see my previous 3 descriptions), so it's never clear what should be in 3.1.2 (or the corresponding sections of other protocols). As a result, I do not understand the purpose of either section of this document, or this document as a whole. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Hi Joe > > My concern is that there is no clear relation between 3.1.2 and 3.1.3. Yes, that’s actually true. Initially there was no section 3.1.2 as this doc is not on interfaces. However it seems to be incomplete without mentioning interfaces at all. If we keep this section, you are right, the relation should be there. > > In fact, many of the properties of 3.1.3 are the result of the interface > mentioned in 3.1.2. Really? Can you give an example? I would rather hope that we can describe the transport components independent of the currently/any interface. > Also, a few aspects of the 3.1.2 interface aren't > considered in 3.1.3. To complete 3.1.3, looking at interface is probably useful. Can you list what’s missing? > > So what's the point of 3.1.3? I’d rather ask what’s the point of 3.1.2…? 3.1.3 is/should become a list of components as basis for discuss which features should/must be exposed to the app-layer. > >> From the definition: > Transport Protocol Component: an implementation of a transport > service feature within a protocol. > > Unfortunately, the items in 3.1.3 aren't implementations; they're > general properties. An implementation would be Reno or CUBIC. I agree that what’s currently listed is not on the right level of detail (see also my other mail to Olivier). Not sure if Reno/Cubic is on the right level either. Maybe it’s delay/loos-based or foreground/background or AIMD, but congestion control is especially complicated I’d say. That’s what we have to figure out now. > > In addition, API isn't defined (e.g., see my previous 3 descriptions), > so it's never clear what should be in 3.1.2 (or the corresponding > sections of other protocols). I don’t know either what should be in 3.1.2 right now. Anything that is useful for 3.1.3 or 4 should be mentioned; everything else will be removed at the end (potentially even the whole section). > > As a result, I do not understand the purpose of either section of this > document, or this document as a whole. That’s to bad. Maybe we should state this more explicitly in the intro…? According to our charter, while taps itself is chartered to describe "an (abstract) interface for applications to make use of Transport Services“, this first document is only used to "identifying the [components] provided by existing IETF protocols“ as a starting point. Further we would like to add some discussion in section 4 which of the identified components should/can be exposed as a transport feature that the app should see. [Note that the terminology changed and whenever services is written in the charter it should basically be component.] Does this help? Mirja > > 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] I-D Action: draft-ietf-taps-transports-04.txt
On 6/1/2015 11:38 AM, Mirja Kühlewind wrote: > Hi Joe >> >> My concern is that there is no clear relation between 3.1.2 and 3.1.3. > > Yes, that’s actually true. Initially there was no section 3.1.2 as > this doc is not on interfaces. However it seems to be incomplete without > mentioning interfaces at all. If we keep this section, you are right, > the relation should be there. Interfaces *define* services: 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. The API defines the information supplied from (and to) the application. Thus, if TAPS doesn't include the API in its flagship document, then I have no idea what you're all doing. >> In fact, many of the properties of 3.1.3 are the result of the interface >> mentioned in 3.1.2. > > Really? Can you give an example? I would rather hope that we can > describe the transport components independent of the currently/any > interface. Your own charter indicates why that is not possible. (Again, I mean "abstract API", not the C or Linux implementations of these). Properties: - stateful result of OPEN and CLOSE commands - active calling party result active/passive OPEN commands i.e., one party needs to actively call the other - byte-oriented, in order result of SEND/RECEIVE calls in order that input/output blocks of bytes in linear sequence - independent of the application data boundaries result of the semantics fo the SEND/RECEIVE calls, which input/output blocks of bytes where the call data boundaries are defined as NOT corresponding to TCP segment boundaries or events - OOB signaling result of PUSH and URG interface >> Also, a few aspects of the 3.1.2 interface aren't >> considered in 3.1.3. > > To complete 3.1.3, looking at interface is probably useful. Can you list > what’s missing? I've done this multiple times already. >> So what's the point of 3.1.3? > > I’d rather ask what’s the point of 3.1.2…? 3.1.3 is/should become a > list of components as basis for discuss which features should/must be > exposed to the app-layer. The list of "components" doesn't fit the definition within this doc, so I disagree with this. >>> From the definition: >> Transport Protocol Component: an implementation of a transport >> service feature within a protocol. >> >> Unfortunately, the items in 3.1.3 aren't implementations; they're >> general properties. An implementation would be Reno or CUBIC. > > I agree that what’s currently listed is not on the right level of > detail (see also my other mail to Olivier). Not sure if Reno/Cubic is on > the right level either. Maybe it’s delay/loos-based or > foreground/background or AIMD, but congestion control is especially > complicated I’d say. That’s what we have to figure out now. You need to update your definitions first if that's the case. >> In addition, API isn't defined (e.g., see my previous 3 descriptions), >> so it's never clear what should be in 3.1.2 (or the corresponding >> sections of other protocols). > > I don’t know either what should be in 3.1.2 right now. Anything that is > useful for 3.1.3 or 4 should be mentioned; everything else will be > removed at the end (potentially even the whole section). The expectations for what are in each section should be defined in this document. Again, if we all don't know what's being written, writing is premature. >> As a result, I do not understand the purpose of either section of this >> document, or this document as a whole. > > That’s to bad. Maybe we should state this more explicitly in the > intro…? According to our charter, while taps itself is chartered to > describe "an (abstract) interface for applications > to make use of Transport Services“, That is an API - more specifically, it's a future, desired abstract API. > this first document is only used to "identifying the > [components] provided by existing IETF protocols“ as a starting > point. IMO, you need to start by defining the current abstract API, then the internal capabilities (independent of implementation) that might be exposed. I don't see how to do that with this "shopping-list" of issues. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
About one bit in particular: > That’s to bad. Maybe we should state this more explicitly in the intro…? > According to our charter, while taps itself is chartered to describe "an > (abstract) interface for applications > to make use of Transport Services“, this first document is only used to > "identifying the > [components] provided by existing IETF protocols“ as a starting point. > Further we would like to add some discussion in section 4 which of the > identified components should/can be exposed as a transport feature that the > app should see. [Note that the terminology changed and whenever services is > written in the charter it should basically be component.] This confuses me. draft-ietf-taps-transports-04 defines a "Transport Protocol Component" as "an implementation of a transport service feature within a protocol." I'm fine with that definition but I can't see why this should replace "service" in the charter. The first document should list the services provided by existing IETF protocols, that's how to get started. Additionally listing components is probably fine if that helps explaining how services are constructed, but the focus is on what transports provide - services. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
I'll try addressing another detail, maybe that helps get us aligned: > On 1. jun. 2015, at 21.38, Mirja Kühlewind > wrote: > > Hi Joe >> >> My concern is that there is no clear relation between 3.1.2 and 3.1.3. > > Yes, that’s actually true. Initially there was no section 3.1.2 as this doc > is not on interfaces. However it seems to be incomplete without mentioning > interfaces at all. If we keep this section, you are right, the relation > should be there. The document is about services. These are provided via interfaces - so the document should very much be about interfaces. 3.1.3 describes TCP, it lists all the things you get with TCP - nothing that the application can configure, but what you get with it anyway. The complete service provided by TCP consists of everything TCP is AND the what the application can configure about it. It gives you segmentation, congestion control, AND it lets you use PUSH and an URGENT pointer and ... Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
On 6/1/2015 12:23 PM, Michael Welzl wrote: > I'll try addressing another detail, maybe that helps get us aligned: > > >> On 1. jun. 2015, at 21.38, Mirja Kühlewind >> wrote: >> >> Hi Joe >>> >>> My concern is that there is no clear relation between 3.1.2 and 3.1.3. >> >> Yes, that’s actually true. Initially there was no section 3.1.2 as this doc >> is not on interfaces. However it seems to be incomplete without mentioning >> interfaces at all. If we keep this section, you are right, the relation >> should be there. > > The document is about services. These are provided via interfaces - so the > document should very much be about interfaces. > 3.1.3 describes TCP, it lists all the things you get with TCP - nothing that > the application can configure, but what you get with it anyway. > > The complete service provided by TCP consists of everything TCP is AND the > what the application can configure about it. Yes. > It gives you segmentation, congestion control, AND it lets you use PUSH > and an URGENT pointer and ... Segmentation is HOW TCP gives you a reliable byte-sequence service over a packet service. It is absolutely NOT something provided to the user or under user control. Users can set MTU values on *some systems*, but that's not part of the TCP API (to the application) nor does MTU necessarily correspond to actual data boundaries (TCP is allowed to do a lot of things). Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 1. jun. 2015, at 23.17, Joe Touch wrote: > > > > On 6/1/2015 12:23 PM, Michael Welzl wrote: >> I'll try addressing another detail, maybe that helps get us aligned: >> >> >>> On 1. jun. 2015, at 21.38, Mirja Kühlewind >>> wrote: >>> >>> Hi Joe My concern is that there is no clear relation between 3.1.2 and 3.1.3. >>> >>> Yes, that’s actually true. Initially there was no section 3.1.2 as this doc >>> is not on interfaces. However it seems to be incomplete without mentioning >>> interfaces at all. If we keep this section, you are right, the relation >>> should be there. >> >> The document is about services. These are provided via interfaces - so the >> document should very much be about interfaces. >> 3.1.3 describes TCP, it lists all the things you get with TCP - nothing that >> the application can configure, but what you get with it anyway. >> >> The complete service provided by TCP consists of everything TCP is AND the >> what the application can configure about it. > > Yes. > >> It gives you segmentation, congestion control, AND it lets you use PUSH >> and an URGENT pointer and ... > > Segmentation is HOW TCP gives you a reliable byte-sequence service over > a packet service. > > It is absolutely NOT something provided to the user or under user > control. Users can set MTU values on *some systems*, but that's not part > of the TCP API (to the application) nor does MTU necessarily correspond > to actual data boundaries (TCP is allowed to do a lot of things). Yes, I didn't mean that segmentation is under user control. Let me rephrase my above sentence: >> It gives you, via its non-configurable static behavior: segmentation, >> congestion control, AND it lets you control some things: PUSH and an >> URGENT pointer and ... Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
On 6/1/2015 1:34 PM, Michael Welzl wrote: >> Segmentation is HOW TCP gives you a reliable byte-sequence service over >> a packet service. >> >> It is absolutely NOT something provided to the user or under user >> control. Users can set MTU values on *some systems*, but that's not part >> of the TCP API (to the application) nor does MTU necessarily correspond >> to actual data boundaries (TCP is allowed to do a lot of things). > > Yes, I didn't mean that segmentation is under user control. Let me rephrase > my above sentence: > >>> It gives you, via its non-configurable static behavior: >>> segmentation, congestion control, AND it lets you control some >>> things: PUSH and an URGENT pointer and ... But it doesn't "give" you segmentation. It uses segmentation to provide a reliable byte stream over a packetized service. If we wanted, we could arguably export a TCP service over a circuit that did NOT need to rely on segmentation. This discussion really needs to distinguish between WHAT TCP exports and HOW TCP makes that happen - the latter may or may not ever be visible to the user. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
I agree with your last statement. We must find a way to distinguish between the features that an application may require and network functionalities that derive from those features. Marie-Jose Montpetit, Ph.D. mari...@mit.edu @SocialTVMIT > On Jun 1, 2015, at 11:22 PM, Joe Touch wrote: > > > > On 6/1/2015 1:34 PM, Michael Welzl wrote: > >>> Segmentation is HOW TCP gives you a reliable byte-sequence service over >>> a packet service. >>> >>> It is absolutely NOT something provided to the user or under user >>> control. Users can set MTU values on *some systems*, but that's not part >>> of the TCP API (to the application) nor does MTU necessarily correspond >>> to actual data boundaries (TCP is allowed to do a lot of things). >> >> Yes, I didn't mean that segmentation is under user control. Let me rephrase >> my above sentence: >> It gives you, via its non-configurable static behavior: segmentation, congestion control, AND it lets you control some things: PUSH and an URGENT pointer and ... > > But it doesn't "give" you segmentation. It uses segmentation to provide > a reliable byte stream over a packetized service. If we wanted, we could > arguably export a TCP service over a circuit that did NOT need to rely > on segmentation. > > This discussion really needs to distinguish between WHAT TCP exports and > HOW TCP makes that happen - the latter may or may not ever be visible to > the user. > > Joe > > ___ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps smime.p7s Description: S/MIME cryptographic signature ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
IMO, this has been an interesting and valuable discussion. One takeaway (for me) is that we have been sloppy in using the terms "interface" as well as "implementation". I think there has been some clarification on the need to document the "interface" for transport protocols. I would further suggest avoiding the term "implementation" which sometimes is used to mean "translate a feature to a mechanism" and sometimes "translate a mechanism to code". Joe's definition of the various meanings of API raise this. --aaron On Tue, Jun 2, 2015 at 2:13 AM, Marie-Jose Montpetit wrote: > I agree with your last statement. We must find a way to distinguish > between the features that an application may require and network > functionalities that derive from those features. > > > > Marie-Jose Montpetit, Ph.D. > mari...@mit.edu > @SocialTVMIT > > > On Jun 1, 2015, at 11:22 PM, Joe Touch wrote: > > > > > > > > On 6/1/2015 1:34 PM, Michael Welzl wrote: > > > >>> Segmentation is HOW TCP gives you a reliable byte-sequence service over > >>> a packet service. > >>> > >>> It is absolutely NOT something provided to the user or under user > >>> control. Users can set MTU values on *some systems*, but that's not > part > >>> of the TCP API (to the application) nor does MTU necessarily correspond > >>> to actual data boundaries (TCP is allowed to do a lot of things). > >> > >> Yes, I didn't mean that segmentation is under user control. Let me > rephrase my above sentence: > >> > It gives you, via its non-configurable static behavior: > segmentation, congestion control, AND it lets you control some > things: PUSH and an URGENT pointer and ... > > > > But it doesn't "give" you segmentation. It uses segmentation to provide > > a reliable byte stream over a packetized service. If we wanted, we could > > arguably export a TCP service over a circuit that did NOT need to rely > > on segmentation. > > > > This discussion really needs to distinguish between WHAT TCP exports and > > HOW TCP makes that happen - the latter may or may not ever be visible to > > the user. > > > > 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 > > ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). Mirja On 01.06.2015 21:12, Michael Welzl wrote: About one bit in particular: That’s to bad. Maybe we should state this more explicitly in the intro…? According to our charter, while taps itself is chartered to describe "an (abstract) interface for applications to make use of Transport Services“, this first document is only used to "identifying the [components] provided by existing IETF protocols“ as a starting point. Further we would like to add some discussion in section 4 which of the identified components should/can be exposed as a transport feature that the app should see. [Note that the terminology changed and whenever services is written in the charter it should basically be component.] This confuses me. draft-ietf-taps-transports-04 defines a "Transport Protocol Component" as "an implementation of a transport service feature within a protocol." I'm fine with that definition but I can't see why this should replace "service" in the charter. The first document should list the services provided by existing IETF protocols, that's how to get started. Additionally listing components is probably fine if that helps explaining how services are constructed, but the focus is on what transports provide - services. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 5. jun. 2015, at 10.12, Mirja Kühlewind > wrote: > > Okay, just to quickly clarify. In the charter only the word service is used. > We defined later on the words component and feature which are currently not > reflected in the charter. The part I've cited below, I think, it should say > components. However, it does not really matter because we will in the current > document first identify components and then discuss features. In any case > this document will not define a new interface. I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... > I'd also say that this is not the flag ship document (as stated by Joe). The > flagship document probably is the third item on the charter which then will > probably also talk about the interface in more detail (charter says on the > third doc: "This document will explain how to select and engage an > appropriate protocol ..."). Well, this first document is no less important, everything hinges on it. So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. That's why I think the service is more important than the component, and that's why I'm on Joe's side here. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
Sorry for sending an extra email - I just had an extra thought and think this is important to add: Below: > On 5. jun. 2015, at 11.05, Michael Welzl wrote: > > >> On 5. jun. 2015, at 10.12, Mirja Kühlewind >> wrote: >> >> Okay, just to quickly clarify. In the charter only the word service is used. >> We defined later on the words component and feature which are currently not >> reflected in the charter. The part I've cited below, I think, it should say >> components. However, it does not really matter because we will in the >> current document first identify components and then discuss features. In any >> case this document will not define a new interface. > > I got that but I disagree about "it should say components" for the part in > the charter: from the definition, the component is an implementation, not > what is exposed to the application. I think the more important part is to > capture what's exposed to the application. For example: SCTP has a component > called "strong error detection (CRC32C)". TCP has a component called "error > detection (checksum)". This is probably not exposed to the application as > such by any of these protocols. I'll explain below why this makes it less > important in my opinion... > > >> I'd also say that this is not the flag ship document (as stated by Joe). The >> flagship document probably is the third item on the charter which then will >> probably also talk about the interface in more detail (charter says on the >> third doc: "This document will explain how to select and engage an >> appropriate protocol ..."). > > Well, this first document is no less important, everything hinges on it. > > So let's think of the future system we're envisioning here. Is it going to > provide "error detection" as a service? Is it going to provide "strong error > detection"? > > When making these decisions, I think we'd first need to go through the list > of things provided to applications by the protocols in what Joe calls the > abstract API. Probably we won't find it there: it's a static property of the > protocols AFAIK. So, next, we go through all the static properties to figure > out what we need to expose. Then, the question becomes: should a TAPS system > decide for or against SCTP based on the level of error protection? Is this a > basis for deciding for this or the other protocol? > > These are important decisions but I think they are secondary, whereas what > the protocols now explicitly offer is primary - because it would be very > strange not to offer what is being offered today. We can decide to not expose > "level of error protection" and give the TAPS more freedom in choosing the > protocol; given that the goal is to stop connection applications to specific > protocols, we CAN do that. as Brian pointed out in a previous email, a protocol comes with a series of what he called "positive properties" and "negative properties". Anyway, properties: your application may like some and hate some. It's always a suite of properties - then, we probably can't expose them individually - e.g. with today's protocols, you can't get MPTCP's usage of multiple paths with coupled congestion control but at the same time have SCTP's strong CRC. Sure, we can say the same about combinations of things that are currently being offered in the abstract APIs of the protocols, but still, things will get easier there: the list is shorter, it's clearer what we need to include and what not (basically everything must be included), and certain API elements will clearly dictate which protocol(s) to use. Therefore I do believe that the job gets much easier if we focus on the abstract APIs first. I'm not against listing the components, it's about what matters more (and it should be reflected in the document accordingly - maybe it could even be an idea to split the document in two, one purely about the "abstract API" and one about "components", and possibly merge them later?). Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 05 Jun 2015, at 11:05, Michael Welzl wrote: > > >> On 5. jun. 2015, at 10.12, Mirja Kühlewind >> wrote: >> >> Okay, just to quickly clarify. In the charter only the word service is used. >> We defined later on the words component and feature which are currently not >> reflected in the charter. The part I've cited below, I think, it should say >> components. However, it does not really matter because we will in the >> current document first identify components and then discuss features. In any >> case this document will not define a new interface. > > I got that but I disagree about "it should say components" for the part in > the charter: from the definition, the component is an implementation, not > what is exposed to the application. I think the more important part is to > capture what's exposed to the application. For example: SCTP has a component > called "strong error detection (CRC32C)". TCP has a component called "error > detection (checksum)". This is probably not exposed to the application as > such by any of these protocols. I'll explain below why this makes it less > important in my opinion... > > >> I'd also say that this is not the flag ship document (as stated by Joe). The >> flagship document probably is the third item on the charter which then will >> probably also talk about the interface in more detail (charter says on the >> third doc: "This document will explain how to select and engage an >> appropriate protocol ..."). > > Well, this first document is no less important, everything hinges on it. > > So let's think of the future system we're envisioning here. Is it going to > provide "error detection" as a service? Is it going to provide "strong error > detection"? > > When making these decisions, I think we'd first need to go through the list > of things provided to applications by the protocols in what Joe calls the > abstract API. Probably we won't find it there: it's a static property of the > protocols AFAIK. So, next, we go through all the static properties to figure > out what we need to expose. Then, the question becomes: should a TAPS system > decide for or against SCTP based on the level of error protection? Is this a > basis for deciding for this or the other protocol? > > These are important decisions but I think they are secondary, whereas what > the protocols now explicitly offer is primary - because it would be very > strange not to offer what is being offered today. We can decide to not expose > "level of error protection" and give the TAPS more freedom in choosing the > protocol; given that the goal is to stop connection applications to specific > protocols, we CAN do that. I consider "protecting against bit errors" a service. And I think the level is important. I agree, TCP and SCTP provide a protocol dependent level of protection, so there is no need to expose this in the API of the particular protocol, however, I do think someone wants a strong checksum or not, and that will influence the choice of protocols. So we do have services which are not configurable via the API. Best regards Michael > > That's why I think the service is more important than the component, and > that's why I'm on Joe's side here. > > 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] I-D Action: draft-ietf-taps-transports-04.txt
Hi Michael, see below. On 05.06.2015 11:05, Michael Welzl wrote: On 5. jun. 2015, at 10.12, Mirja Kühlewind wrote: Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... I don't think that this decision is (in general) that easy. That's why we go through the exercise of decomposing existing protocols into their components and based on this information discuss what potentially could be exposed and further reason about what should be exposed (because there are implications for the application). From my point of view this process it independent of the interface (not matter if we talk about an abstract interface, a certain implementation or what we want to have in future). However, looking at current interfaces will probably help us to make the right decisions. I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). Well, this first document is no less important, everything hinges on it. So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. That's why I think the service is more important than the component, and that's why I'm on Joe's side here. I didn't say anything about the importance of anything. I think all three documents and and all kind of transport 'things' we talk about are important. And most important is the process of getting things 'decomposed' correctly and discussed in the right document at the right time. What I wanted to say is that people who later on read these docs (because they want to use taps), probably only read the third doc, maybe the second, and very likely will only read this document if they already have read the other two and would like have additional information. I do have the feeling that parts of what Joe wants to discuss should however be in the third doc. And therefore I think that the current first doc is not the taps flagship doc because for me a flagship doc (and we probably need to define this term ;-) ) is the doc that you point people to as the first thing to read after the work was finished...? All in all, I actually think that we are on the same side here (and right at this point we don't need too much further discussion). Brian and I are in the process of marking a better distinction on components and feature than what is given in the lists in the current version. I believe the current, very sloppy handing of these lists is where most on the confusion (and potentially disagreement) comes from and I hope that discussion can be more focused soon as we have submitted the next revision. Mirja Cheers, Michael -- -- Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 05 Jun 2015, at 13:29, Mirja Kühlewind > wrote: > > Hi Michael, > > see below. > > > On 05.06.2015 11:05, Michael Welzl wrote: >> >>> On 5. jun. 2015, at 10.12, Mirja Kühlewind >>> wrote: >>> >>> Okay, just to quickly clarify. In the charter only the word service is >>> used. We defined later on the words component and feature which are >>> currently not reflected in the charter. The part I've cited below, I think, >>> it should say components. However, it does not really matter because we >>> will in the current document first identify components and then discuss >>> features. In any case this document will not define a new interface. >> >> I got that but I disagree about "it should say components" for the part in >> the charter: from the definition, the component is an implementation, not >> what is exposed to the application. I think the more important part is to >> capture what's exposed to the application. For example: SCTP has a component >> called "strong error detection (CRC32C)". TCP has a component called "error >> detection (checksum)". This is probably not exposed to the application as >> such by any of these protocols. I'll explain below why this makes it less >> important in my opinion... > > I don't think that this decision is (in general) that easy. That's why we go > through the exercise of decomposing existing protocols into their components > and based on this information discuss what potentially could be exposed and > further reason about what should be exposed (because there are implications > for the application). > > From my point of view this process it independent of the interface (not > matter if we talk about an abstract interface, a certain implementation or > what we want to have in future). However, looking at current interfaces will > probably help us to make the right decisions. > >> >> >>> I'd also say that this is not the flag ship document (as stated by Joe). >>> The flagship document probably is the third item on the charter which then >>> will probably also talk about the interface in more detail (charter says on >>> the third doc: "This document will explain how to select and engage an >>> appropriate protocol ..."). >> >> Well, this first document is no less important, everything hinges on it. >> >> So let's think of the future system we're envisioning here. Is it going to >> provide "error detection" as a service? Is it going to provide "strong error >> detection"? >> >> When making these decisions, I think we'd first need to go through the list >> of things provided to applications by the protocols in what Joe calls the >> abstract API. Probably we won't find it there: it's a static property of the >> protocols AFAIK. So, next, we go through all the static properties to figure >> out what we need to expose. Then, the question becomes: should a TAPS system >> decide for or against SCTP based on the level of error protection? Is this a >> basis for deciding for this or the other protocol? >> >> These are important decisions but I think they are secondary, whereas what >> the protocols now explicitly offer is primary - because it would be very >> strange not to offer what is being offered today. We can decide to not >> expose "level of error protection" and give the TAPS more freedom in >> choosing the protocol; given that the goal is to stop connection >> applications to specific protocols, we CAN do that. >> >> That's why I think the service is more important than the component, and >> that's why I'm on Joe's side here. > > I didn't say anything about the importance of anything. I think all three > documents and and all kind of transport 'things' we talk about are important. > And most important is the process of getting things 'decomposed' correctly > and discussed in the right document at the right time. > > What I wanted to say is that people who later on read these docs (because > they want to use taps), probably only read the third doc, maybe the second, > and very likely will only read this document if they already have read the > other two and would like have additional information. > > I do have the feeling that parts of what Joe wants to discuss should however > be in the third doc. And therefore I think that the current first doc is not > the taps flagship doc because for me a flagship doc (and we probably need to > define this term ;-) ) is the doc that you point people to as the first thing > to read after the work was finished...? > > All in all, I actually think that we are on the same side here (and right at > this point we don't need too much further discussion). Brian and I are in the > process of marking a better distinction on components and feature than what > is given in the lists in the current version. I believe the current, very > sloppy handing of these lists is where most on the confusion (and potentially > disagreement) comes from and I hope that discussion c
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 05 Jun 2015, at 12:35, Michael Tuexen > wrote: > >> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >> >> >>> On 5. jun. 2015, at 10.12, Mirja Kühlewind >>> wrote: >>> >>> Okay, just to quickly clarify. In the charter only the word service is >>> used. We defined later on the words component and feature which are >>> currently not reflected in the charter. The part I've cited below, I think, >>> it should say components. However, it does not really matter because we >>> will in the current document first identify components and then discuss >>> features. In any case this document will not define a new interface. >> >> I got that but I disagree about "it should say components" for the part in >> the charter: from the definition, the component is an implementation, not >> what is exposed to the application. I think the more important part is to >> capture what's exposed to the application. For example: SCTP has a component >> called "strong error detection (CRC32C)". TCP has a component called "error >> detection (checksum)". This is probably not exposed to the application as >> such by any of these protocols. I'll explain below why this makes it less >> important in my opinion... >> >> >>> I'd also say that this is not the flag ship document (as stated by Joe). >>> The flagship document probably is the third item on the charter which then >>> will probably also talk about the interface in more detail (charter says on >>> the third doc: "This document will explain how to select and engage an >>> appropriate protocol ..."). >> >> Well, this first document is no less important, everything hinges on it. >> >> So let's think of the future system we're envisioning here. Is it going to >> provide "error detection" as a service? Is it going to provide "strong error >> detection"? >> >> When making these decisions, I think we'd first need to go through the list >> of things provided to applications by the protocols in what Joe calls the >> abstract API. Probably we won't find it there: it's a static property of the >> protocols AFAIK. So, next, we go through all the static properties to figure >> out what we need to expose. Then, the question becomes: should a TAPS system >> decide for or against SCTP based on the level of error protection? Is this a >> basis for deciding for this or the other protocol? >> >> These are important decisions but I think they are secondary, whereas what >> the protocols now explicitly offer is primary - because it would be very >> strange not to offer what is being offered today. We can decide to not >> expose "level of error protection" and give the TAPS more freedom in >> choosing the protocol; given that the goal is to stop connection >> applications to specific protocols, we CAN do that. > I consider "protecting against bit errors" a service. And I think the level > is important. I agree, TCP and SCTP provide > a protocol dependent level of protection, so there is no need to expose this > in the API of the particular protocol, > however, I do think someone wants a strong checksum or not, and that will > influence the choice of protocols. > So we do have services which are not configurable via the API. Just for clarification: this wasn't about whether the level of "protection against bit errors" as such is important or not: I think the level of protection is a less important item to cover in the first document because, given current protocols (what this doc is about), you can't just switch it on or off - it comes with a choice of a whole protocol. So it's just a part of a protocol description - static protocol properties that come as a whole whenever you pick the protocol. Cheers, Michael ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 05 Jun 2015, at 15:39, Michael Welzl wrote: > > >> On 05 Jun 2015, at 12:35, Michael Tuexen >> wrote: >> >>> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >>> >>> On 5. jun. 2015, at 10.12, Mirja Kühlewind wrote: Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. >>> >>> I got that but I disagree about "it should say components" for the part in >>> the charter: from the definition, the component is an implementation, not >>> what is exposed to the application. I think the more important part is to >>> capture what's exposed to the application. For example: SCTP has a >>> component called "strong error detection (CRC32C)". TCP has a component >>> called "error detection (checksum)". This is probably not exposed to the >>> application as such by any of these protocols. I'll explain below why this >>> makes it less important in my opinion... >>> >>> I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). >>> >>> Well, this first document is no less important, everything hinges on it. >>> >>> So let's think of the future system we're envisioning here. Is it going to >>> provide "error detection" as a service? Is it going to provide "strong >>> error detection"? >>> >>> When making these decisions, I think we'd first need to go through the list >>> of things provided to applications by the protocols in what Joe calls the >>> abstract API. Probably we won't find it there: it's a static property of >>> the protocols AFAIK. So, next, we go through all the static properties to >>> figure out what we need to expose. Then, the question becomes: should a >>> TAPS system decide for or against SCTP based on the level of error >>> protection? Is this a basis for deciding for this or the other protocol? >>> >>> These are important decisions but I think they are secondary, whereas what >>> the protocols now explicitly offer is primary - because it would be very >>> strange not to offer what is being offered today. We can decide to not >>> expose "level of error protection" and give the TAPS more freedom in >>> choosing the protocol; given that the goal is to stop connection >>> applications to specific protocols, we CAN do that. >> I consider "protecting against bit errors" a service. And I think the level >> is important. I agree, TCP and SCTP provide >> a protocol dependent level of protection, so there is no need to expose this >> in the API of the particular protocol, >> however, I do think someone wants a strong checksum or not, and that will >> influence the choice of protocols. >> So we do have services which are not configurable via the API. > > Just for clarification: this wasn't about whether the level of "protection > against bit errors" as such is important or not: I think the level of > protection is a less important item to cover in the first document because, > given current protocols (what this doc is about), you can't just switch it on > or off - it comes with a choice of a whole protocol. So it's just a part of a > protocol description - static protocol properties that come as a whole > whenever you pick the protocol. Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come with choosing TCP... Best regards Michael > > Cheers, > Michael > > ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 05 Jun 2015, at 15:52, Michael Tuexen > wrote: > >> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >> >> >>> On 05 Jun 2015, at 12:35, Michael Tuexen >>> wrote: >>> On 05 Jun 2015, at 11:05, Michael Welzl wrote: > On 5. jun. 2015, at 10.12, Mirja Kühlewind > wrote: > > Okay, just to quickly clarify. In the charter only the word service is > used. We defined later on the words component and feature which are > currently not reflected in the charter. The part I've cited below, I > think, it should say components. However, it does not really matter > because we will in the current document first identify components and > then discuss features. In any case this document will not define a new > interface. I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... > I'd also say that this is not the flag ship document (as stated by Joe). > The flagship document probably is the third item on the charter which > then will probably also talk about the interface in more detail (charter > says on the third doc: "This document will explain how to select and > engage an appropriate protocol ..."). Well, this first document is no less important, everything hinges on it. So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. >>> I consider "protecting against bit errors" a service. And I think the level >>> is important. I agree, TCP and SCTP provide >>> a protocol dependent level of protection, so there is no need to expose >>> this in the API of the particular protocol, >>> however, I do think someone wants a strong checksum or not, and that will >>> influence the choice of protocols. >>> So we do have services which are not configurable via the API. >> >> Just for clarification: this wasn't about whether the level of "protection >> against bit errors" as such is important or not: I think the level of >> protection is a less important item to cover in the first document because, >> given current protocols (what this doc is about), you can't just switch it >> on or off - it comes with a choice of a whole protocol. So it's just a part >> of a protocol description - static protocol properties that come as a whole >> whenever you pick the protocol. > Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come > with choosing TCP... Exactly. I meant "important" as "to be discussed first" (hm, maybe simply "listed first in the doc"). I think it would make things easier and clearer to first discuss the things that are exposed by the abstract APIs today. SCTP will help, then: it exposes "reliable". So if we'd go with that, the first item in your list above for TCP would already disappear from the discussion: it will eventually need to be exposed by a TAPS system because of SCTP anyway, and thus belongs in the list. So if the document would, for instance, first list all the things that the protocol's abstract API now expose, and then follow with static properties that protocols have (and that a certain combination of chosen services would entail), then that list of static properties gets shorter - e.g., for TCP, from the two items above, only "byte stream" would be left. My aim here is to try to simplify things so t
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
On 6/5/2015 4:29 AM, Mirja Kühlewind wrote: > I do have the feeling that parts of what Joe wants to discuss should > however be in the third doc. And therefore I think that the current > first doc is not the taps flagship doc because for me a flagship doc > (and we probably need to define this term ;-) ) is the doc that you > point people to as the first thing to read after the work was finished...? Perhaps "flagship" isn't a useful word for either doc. IMO, this is a "foundation" doc, and as such needs to set the groundwork for other docs. As to what doc we'll point people at when this is done, that could be a BCP, it could be a new protocol (experimental, presumably), etc. But we're nowhere near understanding what that last doc will be if we can't agree on what a protocol or API is. Joe ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
On Friday, June 5, 2015 6:40 AM, Michael Welzl wrote: > > ... > Just for clarification: this wasn't about whether the level of "protection > against > bit errors" as such is important or not: I think the level of protection is a > less > important item to cover in the first document because, given current protocols > (what this doc is about), you can't just switch it on or off - it comes with > a choice > of a whole protocol. So it's just a part of a protocol description - static > protocol > properties that come as a whole whenever you pick the protocol. I don't think that applications care very much about the distinction between CRC32 and 16 bit checksum. The real distinction is between "some protection" and "cryptographic protection," as given for example by SSL/TLS on top of TCP. Obviously the 16 bit checksum 16 will let through more transmission errors than the 32 bit CRC, but errors can also happen "above" the checksum, during the various data manipulations performed by the transport protocols. They can also be due to overactive middleboxes that will change the data and then "fix" the checksum. Applications that are concerned enough about the integrity of the data are going to use crypto end-to-end. Which is an argument for taking a view of service definitions "from the application," rather than merely cataloging what TCP and SCTP can do today. -- Christian Huitema ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 05 Jun 2015, at 16:03, Michael Welzl wrote: > > >> On 05 Jun 2015, at 15:52, Michael Tuexen >> wrote: >> >>> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >>> >>> On 05 Jun 2015, at 12:35, Michael Tuexen wrote: > On 05 Jun 2015, at 11:05, Michael Welzl wrote: > > >> On 5. jun. 2015, at 10.12, Mirja Kühlewind >> wrote: >> >> Okay, just to quickly clarify. In the charter only the word service is >> used. We defined later on the words component and feature which are >> currently not reflected in the charter. The part I've cited below, I >> think, it should say components. However, it does not really matter >> because we will in the current document first identify components and >> then discuss features. In any case this document will not define a new >> interface. > > I got that but I disagree about "it should say components" for the part > in the charter: from the definition, the component is an implementation, > not what is exposed to the application. I think the more important part > is to capture what's exposed to the application. For example: SCTP has a > component called "strong error detection (CRC32C)". TCP has a component > called "error detection (checksum)". This is probably not exposed to the > application as such by any of these protocols. I'll explain below why > this makes it less important in my opinion... > > >> I'd also say that this is not the flag ship document (as stated by Joe). >> The flagship document probably is the third item on the charter which >> then will probably also talk about the interface in more detail (charter >> says on the third doc: "This document will explain how to select and >> engage an appropriate protocol ..."). > > Well, this first document is no less important, everything hinges on it. > > So let's think of the future system we're envisioning here. Is it going > to provide "error detection" as a service? Is it going to provide "strong > error detection"? > > When making these decisions, I think we'd first need to go through the > list of things provided to applications by the protocols in what Joe > calls the abstract API. Probably we won't find it there: it's a static > property of the protocols AFAIK. So, next, we go through all the static > properties to figure out what we need to expose. Then, the question > becomes: should a TAPS system decide for or against SCTP based on the > level of error protection? Is this a basis for deciding for this or the > other protocol? > > These are important decisions but I think they are secondary, whereas > what the protocols now explicitly offer is primary - because it would be > very strange not to offer what is being offered today. We can decide to > not expose "level of error protection" and give the TAPS more freedom in > choosing the protocol; given that the goal is to stop connection > applications to specific protocols, we CAN do that. I consider "protecting against bit errors" a service. And I think the level is important. I agree, TCP and SCTP provide a protocol dependent level of protection, so there is no need to expose this in the API of the particular protocol, however, I do think someone wants a strong checksum or not, and that will influence the choice of protocols. So we do have services which are not configurable via the API. >>> >>> Just for clarification: this wasn't about whether the level of "protection >>> against bit errors" as such is important or not: I think the level of >>> protection is a less important item to cover in the first document because, >>> given current protocols (what this doc is about), you can't just switch it >>> on or off - it comes with a choice of a whole protocol. So it's just a part >>> of a protocol description - static protocol properties that come as a whole >>> whenever you pick the protocol. >> Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come >> with choosing TCP... > > Exactly. > > I meant "important" as "to be discussed first" (hm, maybe simply "listed > first in the doc"). I think it would make things easier and clearer to first > discuss the things that are exposed by the abstract APIs today. > SCTP will help, then: it exposes "reliable". So if we'd go with that, the > first item in your list above for TCP would already disappear from the > discussion: it will eventually need to be exposed by a TAPS system because of > SCTP anyway, and thus belongs in the list. > > So if the document would, for instance, first list all the things that the > protocol's abstract API now expose, and then follow with static properties > that protocols have (and that a certain combination of chosen services would > entail), then
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 5. jun. 2015, at 19.52, Michael Tuexen > wrote: > >> On 05 Jun 2015, at 16:03, Michael Welzl wrote: >> >> >>> On 05 Jun 2015, at 15:52, Michael Tuexen >>> wrote: >>> On 05 Jun 2015, at 15:39, Michael Welzl wrote: > On 05 Jun 2015, at 12:35, Michael Tuexen > wrote: > >> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >> >> >>> On 5. jun. 2015, at 10.12, Mirja Kühlewind >>> wrote: >>> >>> Okay, just to quickly clarify. In the charter only the word service is >>> used. We defined later on the words component and feature which are >>> currently not reflected in the charter. The part I've cited below, I >>> think, it should say components. However, it does not really matter >>> because we will in the current document first identify components and >>> then discuss features. In any case this document will not define a new >>> interface. >> >> I got that but I disagree about "it should say components" for the part >> in the charter: from the definition, the component is an implementation, >> not what is exposed to the application. I think the more important part >> is to capture what's exposed to the application. For example: SCTP has a >> component called "strong error detection (CRC32C)". TCP has a component >> called "error detection (checksum)". This is probably not exposed to the >> application as such by any of these protocols. I'll explain below why >> this makes it less important in my opinion... >> >> >>> I'd also say that this is not the flag ship document (as stated by >>> Joe). The flagship document probably is the third item on the charter >>> which then will probably also talk about the interface in more detail >>> (charter says on the third doc: "This document will explain how to >>> select and engage an appropriate protocol ..."). >> >> Well, this first document is no less important, everything hinges on it. >> >> So let's think of the future system we're envisioning here. Is it going >> to provide "error detection" as a service? Is it going to provide >> "strong error detection"? >> >> When making these decisions, I think we'd first need to go through the >> list of things provided to applications by the protocols in what Joe >> calls the abstract API. Probably we won't find it there: it's a static >> property of the protocols AFAIK. So, next, we go through all the static >> properties to figure out what we need to expose. Then, the question >> becomes: should a TAPS system decide for or against SCTP based on the >> level of error protection? Is this a basis for deciding for this or the >> other protocol? >> >> These are important decisions but I think they are secondary, whereas >> what the protocols now explicitly offer is primary - because it would be >> very strange not to offer what is being offered today. We can decide to >> not expose "level of error protection" and give the TAPS more freedom in >> choosing the protocol; given that the goal is to stop connection >> applications to specific protocols, we CAN do that. > I consider "protecting against bit errors" a service. And I think the > level is important. I agree, TCP and SCTP provide > a protocol dependent level of protection, so there is no need to expose > this in the API of the particular protocol, > however, I do think someone wants a strong checksum or not, and that will > influence the choice of protocols. > So we do have services which are not configurable via the API. Just for clarification: this wasn't about whether the level of "protection against bit errors" as such is important or not: I think the level of protection is a less important item to cover in the first document because, given current protocols (what this doc is about), you can't just switch it on or off - it comes with a choice of a whole protocol. So it's just a part of a protocol description - static protocol properties that come as a whole whenever you pick the protocol. >>> Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come >>> with choosing TCP... >> >> Exactly. >> >> I meant "important" as "to be discussed first" (hm, maybe simply "listed >> first in the doc"). I think it would make things easier and clearer to first >> discuss the things that are exposed by the abstract APIs today. >> SCTP will help, then: it exposes "reliable". So if we'd go with that, the >> first item in your list above for TCP would already disappear from the >> discussion: it will eventually need to be exposed by a TAPS system because >> of SCTP anyway, and thus belongs in the list. >> >> So if the document would, for instance, first list all the things that the >> protocol's abstract
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
> On 05 Jun 2015, at 22:17, Michael Welzl wrote: > > >> On 5. jun. 2015, at 19.52, Michael Tuexen >> wrote: >> >>> On 05 Jun 2015, at 16:03, Michael Welzl wrote: >>> >>> On 05 Jun 2015, at 15:52, Michael Tuexen wrote: > On 05 Jun 2015, at 15:39, Michael Welzl wrote: > > >> On 05 Jun 2015, at 12:35, Michael Tuexen >> wrote: >> >>> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >>> >>> On 5. jun. 2015, at 10.12, Mirja Kühlewind wrote: Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. >>> >>> I got that but I disagree about "it should say components" for the part >>> in the charter: from the definition, the component is an >>> implementation, not what is exposed to the application. I think the >>> more important part is to capture what's exposed to the application. >>> For example: SCTP has a component called "strong error detection >>> (CRC32C)". TCP has a component called "error detection (checksum)". >>> This is probably not exposed to the application as such by any of these >>> protocols. I'll explain below why this makes it less important in my >>> opinion... >>> >>> I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). >>> >>> Well, this first document is no less important, everything hinges on it. >>> >>> So let's think of the future system we're envisioning here. Is it going >>> to provide "error detection" as a service? Is it going to provide >>> "strong error detection"? >>> >>> When making these decisions, I think we'd first need to go through the >>> list of things provided to applications by the protocols in what Joe >>> calls the abstract API. Probably we won't find it there: it's a static >>> property of the protocols AFAIK. So, next, we go through all the static >>> properties to figure out what we need to expose. Then, the question >>> becomes: should a TAPS system decide for or against SCTP based on the >>> level of error protection? Is this a basis for deciding for this or the >>> other protocol? >>> >>> These are important decisions but I think they are secondary, whereas >>> what the protocols now explicitly offer is primary - because it would >>> be very strange not to offer what is being offered today. We can decide >>> to not expose "level of error protection" and give the TAPS more >>> freedom in choosing the protocol; given that the goal is to stop >>> connection applications to specific protocols, we CAN do that. >> I consider "protecting against bit errors" a service. And I think the >> level is important. I agree, TCP and SCTP provide >> a protocol dependent level of protection, so there is no need to expose >> this in the API of the particular protocol, >> however, I do think someone wants a strong checksum or not, and that >> will influence the choice of protocols. >> So we do have services which are not configurable via the API. > > Just for clarification: this wasn't about whether the level of > "protection against bit errors" as such is important or not: I think the > level of protection is a less important item to cover in the first > document because, given current protocols (what this doc is about), you > can't just switch it on or off - it comes with a choice of a whole > protocol. So it's just a part of a protocol description - static protocol > properties that come as a whole whenever you pick the protocol. Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come with choosing TCP... >>> >>> Exactly. >>> >>> I meant "important" as "to be discussed first" (hm, maybe simply "listed >>> first in the doc"). I think it would make things easier and clearer to >>> first discuss the things that are exposed by the abstract APIs today. >>> SCTP will help, then: it exposes "reliable". So if we'd go with that, the >>> first item in your list above for TCP would already disappear from the >>> discussion: it will eventually need to be exposed by a TAPS system because
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
On 2015-06-05 22:17, Michael Welzl wrote: On 5. jun. 2015, at 19.52, Michael Tuexen wrote: On 05 Jun 2015, at 16:03, Michael Welzl wrote: On 05 Jun 2015, at 15:52, Michael Tuexen wrote: On 05 Jun 2015, at 15:39, Michael Welzl wrote: On 05 Jun 2015, at 12:35, Michael Tuexen wrote: On 05 Jun 2015, at 11:05, Michael Welzl wrote: On 5. jun. 2015, at 10.12, Mirja Kühlewind wrote: Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). Well, this first document is no less important, everything hinges on it. So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. I consider "protecting against bit errors" a service. And I think the level is important. I agree, TCP and SCTP provide a protocol dependent level of protection, so there is no need to expose this in the API of the particular protocol, however, I do think someone wants a strong checksum or not, and that will influence the choice of protocols. So we do have services which are not configurable via the API. Just for clarification: this wasn't about whether the level of "protection against bit errors" as such is important or not: I think the level of protection is a less important item to cover in the first document because, given current protocols (what this doc is about), you can't just switch it on or off - it comes with a choice of a whole protocol. So it's just a part of a protocol description - static protocol properties that come as a whole whenever you pick the protocol. Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come with choosing TCP... Exactly. I meant "important" as "to be discussed first" (hm, maybe simply "listed first in the doc"). I think it would make things easier and clearer to first discuss the things that are exposed by the abstract APIs today. SCTP will help, then: it exposes "reliable". So if we'd go with that, the first item in your list above for TCP would already disappear from the discussion: it will eventually need to be exposed by a TAPS system because of SCTP anyway, and thus belongs in the list. So if the document would, for instance, first list all the things that the protocol's abstract API now expose, and then follow with static properties that protocols have (and that a certain combination of chosen services would entail), then that list of static properties gets shorter - e.g., for TCP, from the two items above, only "byte stream" would be left. Structuring the things are a good idea. Which do you get "byte stream", not "reliable byte stream"? Only "byte stream" because you don't need to talk about reliability anymore when you have it covered by going through the abstract APIs. Then
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
I completely agree. Marie-Jose Montpetit, Ph.D. mari...@mit.edu @SocialTVMIT > On Jun 6, 2015, at 12:12 AM, Anna Brunstrom wrote: > > > On 2015-06-05 22:17, Michael Welzl wrote: >>> On 5. jun. 2015, at 19.52, Michael Tuexen >>> wrote: >>> On 05 Jun 2015, at 16:03, Michael Welzl wrote: > On 05 Jun 2015, at 15:52, Michael Tuexen > wrote: > >> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >> >> >>> On 05 Jun 2015, at 12:35, Michael Tuexen >>> wrote: >>> On 05 Jun 2015, at 11:05, Michael Welzl wrote: > On 5. jun. 2015, at 10.12, Mirja Kühlewind > wrote: > > Okay, just to quickly clarify. In the charter only the word service > is used. We defined later on the words component and feature which > are currently not reflected in the charter. The part I've cited > below, I think, it should say components. However, it does not really > matter because we will in the current document first identify > components and then discuss features. In any case this document will > not define a new interface. I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... > I'd also say that this is not the flag ship document (as stated by > Joe). The flagship document probably is the third item on the charter > which then will probably also talk about the interface in more detail > (charter says on the third doc: "This document will explain how to > select and engage an appropriate protocol ..."). Well, this first document is no less important, everything hinges on it. So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. >>> I consider "protecting against bit errors" a service. And I think the >>> level is important. I agree, TCP and SCTP provide >>> a protocol dependent level of protection, so there is no need to expose >>> this in the API of the particular protocol, >>> however, I do think someone wants a strong checksum or not, and that >>> will influence the choice of protocols. >>> So we do have services which are not configurable via the API. >> Just for clarification: this wasn't about whether the level of >> "protection against bit errors" as such is important or not: I think the >> level of protection is a less important item to cover in the first >> document because, given current protocols (what this doc is about), you >> can't just switch it on or off - it comes with a choice of a whole >> protocol. So it's just a part of a protocol description - static >> protocol properties that come as a whole whenever you pick the protocol. > Such as "reliable" for TCP? Or "byte stream" for TCP? These properties > come with choosing TCP... Exactly. I meant "important" as "to be discussed first" (hm, maybe simply "listed first in the doc"). I think it would make things easier and clearer to first discuss the things that are exposed by the abstract APIs today. SCTP will help, then: it exposes "re
Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
I do, too - I didn't mean that we should merge the abstract APIs together right now, in this first doc! This was just about the thought process - while my answer to Michael Tuexen is "yes, I meant the complete abstract API", that was just about what we could eventually get from having a complete view of this API. > On 6. jun. 2015, at 06.37, Marie-Jose Montpetit wrote: > > I completely agree. > > Marie-Jose Montpetit, Ph.D. > mari...@mit.edu > @SocialTVMIT > >> On Jun 6, 2015, at 12:12 AM, Anna Brunstrom wrote: >> >> >> On 2015-06-05 22:17, Michael Welzl wrote: On 5. jun. 2015, at 19.52, Michael Tuexen wrote: > On 05 Jun 2015, at 16:03, Michael Welzl wrote: > > >> On 05 Jun 2015, at 15:52, Michael Tuexen >> wrote: >> >>> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >>> >>> On 05 Jun 2015, at 12:35, Michael Tuexen wrote: > On 05 Jun 2015, at 11:05, Michael Welzl wrote: > > >> On 5. jun. 2015, at 10.12, Mirja Kühlewind >> wrote: >> >> Okay, just to quickly clarify. In the charter only the word service >> is used. We defined later on the words component and feature which >> are currently not reflected in the charter. The part I've cited >> below, I think, it should say components. However, it does not >> really matter because we will in the current document first identify >> components and then discuss features. In any case this document will >> not define a new interface. > I got that but I disagree about "it should say components" for the > part in the charter: from the definition, the component is an > implementation, not what is exposed to the application. I think the > more important part is to capture what's exposed to the application. > For example: SCTP has a component called "strong error detection > (CRC32C)". TCP has a component called "error detection (checksum)". > This is probably not exposed to the application as such by any of > these protocols. I'll explain below why this makes it less important > in my opinion... > > >> I'd also say that this is not the flag ship document (as stated by >> Joe). The flagship document probably is the third item on the >> charter which then will probably also talk about the interface in >> more detail (charter says on the third doc: "This document will >> explain how to select and engage an appropriate protocol ..."). > Well, this first document is no less important, everything hinges on > it. > > So let's think of the future system we're envisioning here. Is it > going to provide "error detection" as a service? Is it going to > provide "strong error detection"? > > When making these decisions, I think we'd first need to go through > the list of things provided to applications by the protocols in what > Joe calls the abstract API. Probably we won't find it there: it's a > static property of the protocols AFAIK. So, next, we go through all > the static properties to figure out what we need to expose. Then, the > question becomes: should a TAPS system decide for or against SCTP > based on the level of error protection? Is this a basis for deciding > for this or the other protocol? > > These are important decisions but I think they are secondary, whereas > what the protocols now explicitly offer is primary - because it would > be very strange not to offer what is being offered today. We can > decide to not expose "level of error protection" and give the TAPS > more freedom in choosing the protocol; given that the goal is to stop > connection applications to specific protocols, we CAN do that. I consider "protecting against bit errors" a service. And I think the level is important. I agree, TCP and SCTP provide a protocol dependent level of protection, so there is no need to expose this in the API of the particular protocol, however, I do think someone wants a strong checksum or not, and that will influence the choice of protocols. So we do have services which are not configurable via the API. >>> Just for clarification: this wasn't about whether the level of >>> "protection against bit errors" as such is important or not: I think >>> the level of protection is a less important item to cover in the first >>> document because, given current protocols (what this doc is about), you >>> can't just switch it on or off - it comes with a choice of a whole >>> protocol. So it's just a part of a protocol description - static >>