Hi all, one more proposal that in not inline with the charter definition but therefore more similar to Gorry’s proposal. Basically we could even avoid to use the term ‚transport service‘ as a stand-alone term and always use ‚transport service <something>‘ instead to make the meaning more explicit (see below). Further in addition to Gorry’s definition below I still think we also need to distinguish something that actually provides a certain implementation based on a concrete protocol/stack etc.
Therefore this proposal: transport service component: e.g reliability transport service composition: a set of components (without any association to a certain framing protocol). transport protocol: an implementation (using a specific framing/header format) providing different transport service service compositions transport protocol feature: an implementation of one certain transport service component e.g. reliability using ACKs (instead of NACKs) transport service instance: one implementation of one service composition utilizing one or multiple protocols with a selected set of features (and a certain parameterization), e.g. a protocol stack (RTP over UDP) or even something that switches between two protocols depending on the network conditions Any comments? Mirja > Am 06.11.2014 um 00:55 schrieb [email protected]: > > > So... > > One of the things I have been trying to understand over the last couple of > weeks is what entities we have to name in TAPS, and how we give the > entities names that seem to be understood by our community and preferably > are common with other uses in the IETF. > > I came across one term that appears to be defined differently in the > charter discussions, to how I would normally understand this. This email > tries to explain this, if you think the same as me, please speak-up and > say this, if you think another definition is better, please say why. > > I think the group just needs to decide at this stage, so that all actual > RFCs that are made will be consistent. > > --- > 1) Transport Service > > I see a "Transport Service" as an end-to-end service that has > traditionally been mapped by transport people down to a "port/socket" > (perhaps the "S" part of tsv). > > This appears consistent with other uses, I have come across. However, a > service is usually composed of a number of "components" - I seem to recall > these be called "service elements" in OSI. Examples are: reliability, > multicast, confirmed delivery, congestion control, integrity, minimal > latency, etc. (we could, and probably should make a list). > > Application > | > Transport Service(s) > | | > Service Service > Component Component(s) > > Hence, I see a service as offered via an API to an App or upper-layer > protocol. I see a service as having multiple components. This is not > necessarily the usage in the final charter fro TAPS!! > > --- > > 2) When the charter says; "Four examples of Transport Services are reliable > delivery, ordered delivery of data, content privacy to in-path > devices, and minimal latency." > > - I think these could indeed be transport services, but I'd actually now > suggest they could be better described as components/elements of a > transport service. In my thinking, one could always build an entire > service that was oriented at "minimal latency" - but equally one could > conceive of this as a transport service component that could be combined > with security, ordering, etc. (using the language above). > > --- > > 3) Transport Protocols > > Transport protocols are not a service, because many transport protocols > can provide multiple services (again my own terminology). Indeed a single > transport can negotiate to support multiple "features". A "feature" > represents a choice of protocol mechanisms/parameters to instantiate a > service (or one component of a service, e.g. use of ECN, optional > integrity > checks, etc). This term has been sued before, one of the older uses could > be FTP feature negotiation. DCCP formally included "features" in its > protocol design. > > Transport protocol > | | > Feature Feature(s) > | > Protocol > mechanism(s) > > --- > > For anyone in fear this is endless, it is NOT going to be. Mirja will > present slides to ask for confirmation of the hierarchy terms at the > meeting next week, and after a <shot> discussion we plan to very quickly > and publish a new revised ID with the WG-"approved" terms and use these > hence-forth. > > Gorry > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
