subject:"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

2015-06-01 Thread Mirja Kühlewind

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

2015-06-01 Thread Mirja Kühlewind

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

2015-06-01 Thread Marie-Jose Montpetit

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

2015-06-02 Thread Aaron Falk

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

2015-06-05 Thread Mirja Kühlewind

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

2015-06-05 Thread Mirja Kühlewind

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

2015-06-05 Thread Joe Touch

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

2015-06-05 Thread Christian Huitema

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