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
