On 6/8/2015 1:19 AM, Mirja Kühlewind wrote:
> Hi Joe,
>
> the document defines one more term:
>
> Transport Service Instance: an arrangement of transport protocols
> with a selected set of features and configuration parameters that
> implements a single transport service, e.g. a protocol stack (RTP
> over UDP).
>
> This is to describe also a stack of protocols which an application
> might use to get a certain transport service. (we might need to re-write
> this maybe, because I now have the feeling that this is hard to understand).
If that's what it means, it certainly needs to be rewritten. A substack
of protocols isn't "an arrangement of transport protocols". The former
is vertical and involves functional composition; the latter is
horizontal ("peers" in the ISO stack at L4) and involves the union of
capabilities of the peers.
> Currently we are not using this term in this document because we try
> to describe components of anything that might/could provide a transport
> service feature of all protocols that that might be part of a protocol
> stack that can be accessed by an application.
I don't understand that either.
I really think that the definitions need to decouple the concept of
service interface to the upper layer from mechanisms that provide those
services.
> That’s what we had in mind when we came up with this terminology and
> I think think it covers the case where HTTP over TCP is used as a
> transport ‚substitute‘.
HTTP isn't a transport protocol. I don't know anyone who would call it
that or be able to use it as a substitute for TCP.
Joe
> Mirja
>
>
>
>> Am 04.06.2015 um 23:20 schrieb Joe Touch <[email protected]>:
>>
>>
>>
>> On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote:
>>> In my presentation in Dallas I had suggested adding RTP (and even
>>> HTTP) because as both Mirja and Christian mention some 'applications'
>>> are requesting functionalities that are got given elsewhere.
>>
>> The core of this issue is "what is a transport protocol".
>>
>> To the user, "transport" is the entire stack between their program and
>> the network (IP) layer - sometimes even including that (e.g., IPsec).
>>
>> To typical transport protocols (e.g., UDP, TCP), everything that
>> accesses a transport protocol is the "application" layer.
>>
>>> From the document:
>> Transport Service: a set of transport service features, without an
>> association to any given framing protocol, which provides a
>> complete service to an application.
>>
>> Transport Protocol: an implementation that provides one or more
>> different transport services using a specific framing and header
>> format on the wire.
>>
>> By those definitions, EVERYTHING between the user program and the link
>> layer is arguably part of the services an app sees, which include "shim"
>> services and layers such as: IPsec, TLS, and RTP.
>>
>> I would argue that HTTP is the application that uses TCP (or TLS/TCP),
>> but not a separate service, but that's true only for conventional web
>> service.
>>
>> There are many services built on top of HTTP, at which point HTTP is
>> just another part of what this document calls a "transport service".
>>
>> As a result, unless you'll be describing every possible stack between
>> the user program and the link layer, this document cannot proceed with
>> the current definitions.
>>
>> Joe
>
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
