Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Marie-Jose Montpetit]

I completely agree.

Marie-Jose Montpetit, Ph.D.
mari...@mit.edu
@SocialTVMIT

> On Jun 6, 2015, at 12:12 AM, Anna Brunstrom  wrote:
> 
> 
> On 2015-06-05 22:17, Michael Welzl wrote:
>>> On 5. jun. 2015, at 19.52, Michael Tuexen 
>>>  wrote:
>>> 
 On 05 Jun 2015, at 16:03, Michael Welzl  wrote:
 
 
> On 05 Jun 2015, at 15:52, Michael Tuexen 
>  wrote:
> 
>> On 05 Jun 2015, at 15:39, Michael Welzl  wrote:
>> 
>> 
>>> On 05 Jun 2015, at 12:35, Michael Tuexen 
>>>  wrote:
>>> 
 On 05 Jun 2015, at 11:05, Michael Welzl  wrote:
 
 
> On 5. jun. 2015, at 10.12, Mirja Kühlewind 
>  wrote:
> 
> Okay, just to quickly clarify. In the charter only the word service 
> is used. We defined later on the words component and feature which 
> are currently not reflected in the charter. The part I've cited 
> below, I think, it should say components. However, it does not really 
> matter because we will in the current document first identify 
> components and then discuss features. In any case this document will 
> not define a new interface.
 I got that but I disagree about "it should say components" for the 
 part in the charter: from the definition, the component is an 
 implementation, not what is exposed to the application. I think the 
 more important part is to capture what's exposed to the application. 
 For example: SCTP has a component called "strong error detection 
 (CRC32C)". TCP has a component called "error detection (checksum)". 
 This is probably not exposed to the application as such by any of 
 these protocols. I'll explain below why this makes it less important 
 in my opinion...
 
 
> I'd also say that this is not the flag ship document (as stated by 
> Joe). The flagship document probably is the third item on the charter 
> which then will probably also talk about the interface in more detail 
> (charter says on the third doc: "This document will explain how to 
> select and engage an appropriate protocol ...").
 Well, this first document is no less important, everything hinges on 
 it.
 
 So let's think of the future system we're envisioning here. Is it 
 going to provide "error detection" as a service? Is it going to 
 provide "strong error detection"?
 
 When making these decisions, I think we'd first need to go through the 
 list of things provided to applications by the protocols in what Joe 
 calls the abstract API. Probably we won't find it there: it's a static 
 property of the protocols AFAIK. So, next, we go through all the 
 static properties to figure out what we need to expose. Then, the 
 question becomes: should a TAPS system decide for or against SCTP 
 based on the level of error protection? Is this a basis for deciding 
 for this or the other protocol?
 
 These are important decisions but I think they are secondary, whereas 
 what the protocols now explicitly offer is primary - because it would 
 be very strange not to offer what is being offered today. We can 
 decide to not expose "level of error protection" and give the TAPS 
 more freedom in choosing the protocol; given that the goal is to stop 
 connection applications to specific protocols, we CAN do that.
>>> I consider "protecting against bit errors" a service. And I think the 
>>> level is important. I agree, TCP and SCTP provide
>>> a protocol dependent level of protection, so there is no need to expose 
>>> this in the API of the particular protocol,
>>> however, I do think someone wants a strong checksum or not, and that 
>>> will influence the choice of protocols.
>>> So we do have services which are not configurable via the API.
>> Just for clarification: this wasn't about whether the level of 
>> "protection against bit errors" as such is important or not: I think the 
>> level of protection is a less important item to cover in the first 
>> document because, given current protocols (what this doc is about), you 
>> can't just switch it on or off - it comes with a choice of a whole 
>> protocol. So it's just a part of a protocol description - static 
>> protocol properties that come as a whole whenever you pick the protocol.
> Such as "reliable" for TCP? Or "byte stream" for TCP? These properties 
> come with choosing TCP...
 Exactly.
 
 I meant "important" as "to be discussed first" (hm, maybe simply "listed 
 first in the doc"). I think it would make things easier and clearer to 
 first discuss the things that are exposed by the abstract APIs today.
 SCTP will help, then: it exposes "re

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Anna Brunstrom]

On 2015-06-05 22:17, Michael Welzl wrote:

On 5. jun. 2015, at 19.52, Michael Tuexen  
wrote:


On 05 Jun 2015, at 16:03, Michael Welzl  wrote:



On 05 Jun 2015, at 15:52, Michael Tuexen  
wrote:


On 05 Jun 2015, at 15:39, Michael Welzl  wrote:



On 05 Jun 2015, at 12:35, Michael Tuexen  
wrote:


On 05 Jun 2015, at 11:05, Michael Welzl  wrote:



On 5. jun. 2015, at 10.12, Mirja Kühlewind  
wrote:

Okay, just to quickly clarify. In the charter only the word service is used. We 
defined later on the words component and feature which are currently not 
reflected in the charter. The part I've cited below, I think, it should say 
components. However, it does not really matter because we will in the current 
document first identify components and then discuss features. In any case this 
document will not define a new interface.

I got that but I disagree about "it should say components" for the part in the charter: from the 
definition, the component is an implementation, not what is exposed to the application. I think the more 
important part is to capture what's exposed to the application. For example: SCTP has a component called 
"strong error detection (CRC32C)". TCP has a component called "error detection 
(checksum)". This is probably not exposed to the application as such by any of these protocols. I'll 
explain below why this makes it less important in my opinion...



I'd also say that this is not the flag ship document (as stated by Joe). The flagship 
document probably is the third item on the charter which then will probably also talk 
about the interface in more detail (charter says on the third doc: "This document 
will explain how to select and engage an appropriate protocol ...").

Well, this first document is no less important, everything hinges on it.

So let's think of the future system we're envisioning here. Is it going to provide "error 
detection" as a service? Is it going to provide "strong error detection"?

When making these decisions, I think we'd first need to go through the list of 
things provided to applications by the protocols in what Joe calls the abstract 
API. Probably we won't find it there: it's a static property of the protocols 
AFAIK. So, next, we go through all the static properties to figure out what we 
need to expose. Then, the question becomes: should a TAPS system decide for or 
against SCTP based on the level of error protection? Is this a basis for 
deciding for this or the other protocol?

These are important decisions but I think they are secondary, whereas what the protocols 
now explicitly offer is primary - because it would be very strange not to offer what is 
being offered today. We can decide to not expose "level of error protection" 
and give the TAPS more freedom in choosing the protocol; given that the goal is to stop 
connection applications to specific protocols, we CAN do that.

I consider "protecting against bit errors" a service. And I think the level is 
important. I agree, TCP and SCTP provide
a protocol dependent level of protection, so there is no need to expose this in 
the API of the particular protocol,
however, I do think someone wants a strong checksum or not, and that will 
influence the choice of protocols.
So we do have services which are not configurable via the API.

Just for clarification: this wasn't about whether the level of "protection against 
bit errors" as such is important or not: I think the level of protection is a less 
important item to cover in the first document because, given current protocols (what this 
doc is about), you can't just switch it on or off - it comes with a choice of a whole 
protocol. So it's just a part of a protocol description - static protocol properties that 
come as a whole whenever you pick the protocol.

Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come 
with choosing TCP...

Exactly.

I meant "important" as "to be discussed first" (hm, maybe simply "listed first in 
the doc"). I think it would make things easier and clearer to first discuss the things that are exposed 
by the abstract APIs today.
SCTP will help, then: it exposes "reliable". So if we'd go with that, the first 
item in your list above for TCP would already disappear from the discussion: it will 
eventually need to be exposed by a TAPS system because of SCTP anyway, and thus belongs 
in the list.

So if the document would, for instance, first list all the things that the protocol's 
abstract API now expose, and then follow with static properties that protocols have (and 
that a certain combination of chosen services would entail), then that list of static 
properties gets shorter - e.g., for TCP, from the two items above, only "byte 
stream" would be left.

Structuring the things are a good idea. Which do you get "byte stream", not 
"reliable byte stream"?

Only "byte stream" because you don't need to talk about reliability anymore 
when you have it covered by going through the abstract APIs.

Then

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Tuexen]

> On 05 Jun 2015, at 22:17, Michael Welzl  wrote:
> 
> 
>> On 5. jun. 2015, at 19.52, Michael Tuexen  
>> wrote:
>> 
>>> On 05 Jun 2015, at 16:03, Michael Welzl  wrote:
>>> 
>>> 
 On 05 Jun 2015, at 15:52, Michael Tuexen 
  wrote:
 
> On 05 Jun 2015, at 15:39, Michael Welzl  wrote:
> 
> 
>> On 05 Jun 2015, at 12:35, Michael Tuexen 
>>  wrote:
>> 
>>> On 05 Jun 2015, at 11:05, Michael Welzl  wrote:
>>> 
>>> 
 On 5. jun. 2015, at 10.12, Mirja Kühlewind 
  wrote:
 
 Okay, just to quickly clarify. In the charter only the word service is 
 used. We defined later on the words component and feature which are 
 currently not reflected in the charter. The part I've cited below, I 
 think, it should say components. However, it does not really matter 
 because we will in the current document first identify components and 
 then discuss features. In any case this document will not define a new 
 interface.
>>> 
>>> I got that but I disagree about "it should say components" for the part 
>>> in the charter: from the definition, the component is an 
>>> implementation, not what is exposed to the application. I think the 
>>> more important part is to capture what's exposed to the application. 
>>> For example: SCTP has a component called "strong error detection 
>>> (CRC32C)". TCP has a component called "error detection (checksum)". 
>>> This is probably not exposed to the application as such by any of these 
>>> protocols. I'll explain below why this makes it less important in my 
>>> opinion...
>>> 
>>> 
 I'd also say that this is not the flag ship document (as stated by 
 Joe). The flagship document probably is the third item on the charter 
 which then will probably also talk about the interface in more detail 
 (charter says on the third doc: "This document will explain how to 
 select and engage an appropriate protocol ...").
>>> 
>>> Well, this first document is no less important, everything hinges on it.
>>> 
>>> So let's think of the future system we're envisioning here. Is it going 
>>> to provide "error detection" as a service? Is it going to provide 
>>> "strong error detection"?
>>> 
>>> When making these decisions, I think we'd first need to go through the 
>>> list of things provided to applications by the protocols in what Joe 
>>> calls the abstract API. Probably we won't find it there: it's a static 
>>> property of the protocols AFAIK. So, next, we go through all the static 
>>> properties to figure out what we need to expose. Then, the question 
>>> becomes: should a TAPS system decide for or against SCTP based on the 
>>> level of error protection? Is this a basis for deciding for this or the 
>>> other protocol?
>>> 
>>> These are important decisions but I think they are secondary, whereas 
>>> what the protocols now explicitly offer is primary - because it would 
>>> be very strange not to offer what is being offered today. We can decide 
>>> to not expose "level of error protection" and give the TAPS more 
>>> freedom in choosing the protocol; given that the goal is to stop 
>>> connection applications to specific protocols, we CAN do that.
>> I consider "protecting against bit errors" a service. And I think the 
>> level is important. I agree, TCP and SCTP provide
>> a protocol dependent level of protection, so there is no need to expose 
>> this in the API of the particular protocol,
>> however, I do think someone wants a strong checksum or not, and that 
>> will influence the choice of protocols.
>> So we do have services which are not configurable via the API.
> 
> Just for clarification: this wasn't about whether the level of 
> "protection against bit errors" as such is important or not: I think the 
> level of protection is a less important item to cover in the first 
> document because, given current protocols (what this doc is about), you 
> can't just switch it on or off - it comes with a choice of a whole 
> protocol. So it's just a part of a protocol description - static protocol 
> properties that come as a whole whenever you pick the protocol.
 Such as "reliable" for TCP? Or "byte stream" for TCP? These properties 
 come with choosing TCP...
>>> 
>>> Exactly.
>>> 
>>> I meant "important" as "to be discussed first" (hm, maybe simply "listed 
>>> first in the doc"). I think it would make things easier and clearer to 
>>> first discuss the things that are exposed by the abstract APIs today.
>>> SCTP will help, then: it exposes "reliable". So if we'd go with that, the 
>>> first item in your list above for TCP would already disappear from the 
>>> discussion: it will eventually need to be exposed by a TAPS system because 

Re: [Taps] A proposal to throw out RTP

[Mohamed Oulmahdi]

I agree, the discussion should be better  structured ...

On Fri, Jun 5, 2015 at 10:21 PM, Joe Touch  wrote:

>
>
> On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
> >
> >
> > On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch  > > wrote:
> >
> >
> >
> > On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> > > I think that speaking specifically about any protocol in this
> document
> > > will not be in the sens of an "abstract" interface for the
> Transport
> > > layer, because abstraction means that application will no longer be
> > > aware of who or what Transport services are really offered.
> >
> > We need to be more clear in what we are discussing.
> >
> > E.g., an "abstract API" (as I've been calling it) is described as in
> RFC
> > 793:
> >
> > OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS
> >
> > That's abstract only in the sense that it does NOT specify an
> > implementation in Linux, for example. It is not so abstract that it
> > applies to all transports - it's indicated for TCP only.
> >
> > This definition of 'abstract interface" is specific for a given
> > protocol, but the aim in TAPS is a higher level (services). In other
> > words, if this is the définition of an abstract interface, and is
> > already defined in RFC 793, what will be the contribution of TAPS by
> > defining its abstract interface?
>
> The first step towards a universal abstract interface is to understand
> the current specific abstract interfaces. That's what the current
> document is focused on.
>
> > The objective of TAPS is to change the traditional way to use the
> > Transport layer. In fact, traditionally, applications select the
> > appropriate transport service by selecting a given transport protocol.
> > The TAPS vision is to change this, so as applications will request only
> > their desired services, via this abstract interface, and it is to the
> > Transport layer to choose the appropriate protocol according to the
> > application request. It is this level of abstraction that is aimed by
> > TAPS. (see the charter, point 3 especially)
>
> In order to unify or further abstract the API, the current API needs to
> be understood - but the discussion on the list indicates a lot of
> disagreement on this.
>
> Joe
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] A proposal to throw out RTP

[Joe Touch]

On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
> 
> 
> On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch  > wrote:
> 
> 
> 
> On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> > I think that speaking specifically about any protocol in this document
> > will not be in the sens of an "abstract" interface for the Transport
> > layer, because abstraction means that application will no longer be
> > aware of who or what Transport services are really offered.
> 
> We need to be more clear in what we are discussing.
> 
> E.g., an "abstract API" (as I've been calling it) is described as in RFC
> 793:
> 
> OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS
> 
> That's abstract only in the sense that it does NOT specify an
> implementation in Linux, for example. It is not so abstract that it
> applies to all transports - it's indicated for TCP only.
> 
> This definition of 'abstract interface" is specific for a given
> protocol, but the aim in TAPS is a higher level (services). In other
> words, if this is the définition of an abstract interface, and is
> already defined in RFC 793, what will be the contribution of TAPS by
> defining its abstract interface?

The first step towards a universal abstract interface is to understand
the current specific abstract interfaces. That's what the current
document is focused on.

> The objective of TAPS is to change the traditional way to use the
> Transport layer. In fact, traditionally, applications select the
> appropriate transport service by selecting a given transport protocol.
> The TAPS vision is to change this, so as applications will request only
> their desired services, via this abstract interface, and it is to the
> Transport layer to choose the appropriate protocol according to the
> application request. It is this level of abstraction that is aimed by
> TAPS. (see the charter, point 3 especially)

In order to unify or further abstract the API, the current API needs to
be understood - but the discussion on the list indicates a lot of
disagreement on this.

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

[Michael Welzl]

> 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] A proposal to throw out RTP

[Mohamed Oulmahdi]

On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch  wrote:

>
>
> On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> > I think that speaking specifically about any protocol in this document
> > will not be in the sens of an "abstract" interface for the Transport
> > layer, because abstraction means that application will no longer be
> > aware of who or what Transport services are really offered.
>
> We need to be more clear in what we are discussing.
>
> E.g., an "abstract API" (as I've been calling it) is described as in RFC
> 793:
>
> OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS
>
> That's abstract only in the sense that it does NOT specify an
> implementation in Linux, for example. It is not so abstract that it
> applies to all transports - it's indicated for TCP only.
>

This definition of 'abstract interface" is specific for a given protocol,
but the aim in TAPS is a higher level (services). In other words, if this
is the définition of an abstract interface, and is already defined in RFC
793, what will be the contribution of TAPS by defining its abstract
interface?

The objective of TAPS is to change the traditional way to use the Transport
layer. In fact, traditionally, applications select the appropriate
transport service by selecting a given transport protocol. The TAPS vision
is to change this, so as applications will request only their desired
services, via this abstract interface, and it is to the Transport layer to
choose the appropriate protocol according to the application request. It is
this level of abstraction that is aimed by TAPS. (see the charter, point 3
especially)

>
> What you're proposing is a "universal interface", whether abstract
> (described as above, using words to describe app-level actions and
> events) or instantiated (e.g., using Unix socket(), connect(), accept(),
> listen(), etc.).
>
> 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

[Michael Tuexen]

> 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

[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] A proposal to throw out RTP

[Joe Touch]

On 6/5/2015 5:11 AM, Helge Backhaus wrote:
> Am 04.06.2015 um 23:20 schrieb Joe Touch:
...
>> 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,
> 
> Shouldn't this ideally be the (long-term) goal of TAPS?

This would require an exponential number of service descriptions.

IMO, it's better to describe them as a linear number of composable
components and declare the composition rules.

(that's not novel; that's what we do throughout the IETF)

>> this document cannot proceed with the current definitions.
> 
> So could a possible way forward be to leave the definitions as they are
> and add a description of the considered stack(s) to the document? For
> now "just" TCP, UDP, SCTP, ... over IPv4/6 etc.

If you ignore the deficiency of the definitions, then it's impossible to
move together on the remainder of the doc.

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

[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] TAPS Transports and ICMP

[Joe Touch]

On 6/5/2015 12:25 AM, Pal Martinsen (palmarti) wrote:
> 
>> On 04 Jun 2015, at 22:56, Joe Touch > > wrote:
>>
>>
>>
>> On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:
>>>
 On 04 Jun 2015, at 21:17, Joe Touch >>> > wrote:



 On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
 ...
>> UDP passes all ICMP messages to the app. If the app doesn't listen for
>> it, that’s the app's decision.
>>
> Then there is a lot UDP application developers out there that does
> not care. 
>
> Ill guess what I am asking if we should make life easier for them.

 Again, FIRST this doc needs to explain the current abstract APIs for
 transport protocols.

 THEN we can decide whether that set either needs to be augmented,
 diminished, or translated to be more useful for “applications".
>>>
>>> Heh.. I still do not get that..
>>>
 From the Abstract:
>>> This document describes services provided by existing IETF protocols
>>> and congestion control mechanisms.
>>
>> *existing*
>>
>> That means we need to document WHAT IS before deciding to pursue WHAT
>> SHOULD BE.
>>
> ICMP is an *existing* protocol. Not a transport protocol, but a
> service(?) that affects how the other protocols behaves.

And it is part of the service provided by a transport - i.e., when an
ICMP message is absorbed and acted on by TCP, it's a service *to* TCP,
but when TCP relays ICMP messages to the application they become part of
the TCP API.

> All I am observing is that this is something app developers rarely cares
> about, and having sections in the TAPS transports draft describing it
> might help. Why are there sections describing TCP, they could just read
> RFC 793?

More like RFC1122, which already does for TCP and UDP basically what
this doc is attempting to do.

>>> It is designed to help
>>> application and network stack programmers and to inform the work of
>>> the IETF TAPS Working Group.
>>>
>>>
>>> Having a description of how ICMP works. Both in theory (abstract
>>> APIs) and in practice would help app developers.
>>
>> In theory, it behaves like RFC 792 and RFC 1122 specify.
>>
>> In practice, we can measure whether those capabilities are supported or
>> not (but that's not particularly the scope of TAPS).
>>
>> However, that does not necessarily require documenting the Java
>> interface to TCP on Linux CentOS v7. That what man pages are for.
>>
> 
> No, but pointing out that there are differences out there and app
> developers should take care and investigate is a useful hint. 

One line:

Implementations vary.

What else is there to say? And do we really need to say that?

>>> Unfortunately how to do this varies from OS to OS:
>>> See 
>>> https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2
>>>  for
>>> examples.
>>
>> You are confusing the OS and language-dependent implementation of the
>> API with the abstract API.
>>
> On purpose. I hate it when a feature should work because it says so 
> in a RFC, but the implementations of it is so vastly different that
> it is not possible to get the thing to work so the app developer just
> chose to ignore it.

 The IETF standardizes protocols and abstract APIs.

 If you are concerned with differences in the implementations of those
 abstract APIs, you need to address them in other organizations (e.g.,
 POSIX, etc.).

>>>
>>> That seems like a fun task.. (So who is on the list: Apple,
>>> Microsoft, Google(android), Linux, BSD…)
>>
>> POSIX is maintained by the IEEE, and defines the common API across
>> various OS implementations - and yes, some of those orgs participate.
>>
>> That’s far outside the scope of the IETF, though.
> 
> 
> That I agree on. The discussion is probably better had over a beer. I do
> feel that it is important that IETF do take into account what is
> actually used in the wild. 

That would require a survey, not merely anecdotal evidence.

 ...
>> RFC1122 requires that UDP implementations make the ICMP signals
>> available to the application. It does not indicate by what mechanism.
>>
>>> Listening for port unreachable can be nice to avoid spamming a
>>> host or
>>> application that recently crashed. Detecting fragmentation or max
>>> MTU is
>>> also a nice feature especially VoIP applications sending video can
>>> utilise to optimise their packet sizes. 
>>
>> UDP is required to pass ALL ICMP messages to the app layer, as per
>> RFC 1122.
>
> That is another problem. An app using port  will receive all
> ICMP messages also generated by other apps running on other ports.

 That's an incorrect implementation. See RFC1122 Section 4.1.3.3.

>>> The section says:
>>> UDP MUST pass to the application layer all ICMP error
>>> messages that it receives from the IP layer.

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[Michael Welzl]

> 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

[Michael Tuexen]

> 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

[Michael Welzl]

> 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

[Michael Welzl]

> 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] A proposal to throw out RTP

[Helge Backhaus]

Am 04.06.2015 um 23:20 schrieb Joe Touch:



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,


Shouldn't this ideally be the (long-term) goal of TAPS?

Of course it will never be feasible to consider every conceivable existing or 
future stack in practice. Thankfully, since it has been stated multiple times 
that TAPS is not intended to replace everything that exists out there, it's 
maybe good enough to have a look at some stacks...?



this document cannot proceed with the current definitions.


So could a possible way forward be to leave the definitions as they are and add 
a description of the considered stack(s) to the document? For now "just" TCP, 
UDP, SCTP, ... over IPv4/6 etc.


At a later point that could be updated to services provided by the same stack 
with RTP and the likes on top and a third with HTTP over TCP(/TLS) ... the goal 
being to at least cover the "popular" stack (combinations) at some point.


Wouldn't that help to simplify the discussion which protocols are in and out of 
scope as service providers at a given point in time a lot?



Joe


Apologies for just barging in like that. Im a long-time TAPS lurker so to speak 
and genuinely interested in opinions regarding such an approach.


Helge

--
Karlsruhe Institute of Technology (KIT)
Institut für Telematik

Dipl.-Inform. Helge Backhaus
research assistant

Zirkel 2
Building 20.20
Room 352

D-76128 Karlsruhe

phone: +49 721 608 46402

backh...@kit.edu
www.tm.kit.edu
KIT – Universität des Landes Baden-Württemberg und
nationales Großforschungszentrum in der Helmholtz-Gemeinschaft


___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

[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

[Michael Tuexen]

> 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

[Michael Welzl]

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

[Michael Welzl]

> 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

[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] TAPS Transports and ICMP

[Pal Martinsen (palmarti)]

On 04 Jun 2015, at 22:56, Joe Touch mailto:to...@isi.edu>> wrote:



On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote:

On 04 Jun 2015, at 21:17, Joe Touch mailto:to...@isi.edu>> wrote:



On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote:
...
UDP passes all ICMP messages to the app. If the app doesn't listen for
it, that’s the app's decision.

Then there is a lot UDP application developers out there that does not care.

Ill guess what I am asking if we should make life easier for them.

Again, FIRST this doc needs to explain the current abstract APIs for
transport protocols.

THEN we can decide whether that set either needs to be augmented,
diminished, or translated to be more useful for “applications".

Heh.. I still do not get that..

From the Abstract:
This document describes services provided by existing IETF protocols
and congestion control mechanisms.

*existing*

That means we need to document WHAT IS before deciding to pursue WHAT
SHOULD BE.

ICMP is an *existing* protocol. Not a transport protocol, but a service(?) that 
affects how the other protocols behaves.

All I am observing is that this is something app developers rarely cares about, 
and having sections in the TAPS transports draft describing it might help. Why 
are there sections describing TCP, they could just read RFC 793?


It is designed to help
application and network stack programmers and to inform the work of
the IETF TAPS Working Group.


Having a description of how ICMP works. Both in theory (abstract
APIs) and in practice would help app developers.

In theory, it behaves like RFC 792 and RFC 1122 specify.

In practice, we can measure whether those capabilities are supported or
not (but that's not particularly the scope of TAPS).

However, that does not necessarily require documenting the Java
interface to TCP on Linux CentOS v7. That what man pages are for.


No, but pointing out that there are differences out there and app developers 
should take care and investigate is a useful hint.

Unfortunately how to do this varies from OS to OS:
See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 
for
examples.

You are confusing the OS and language-dependent implementation of the
API with the abstract API.

On purpose. I hate it when a feature should work because it says so
in a RFC, but the implementations of it is so vastly different that
it is not possible to get the thing to work so the app developer just
chose to ignore it.

The IETF standardizes protocols and abstract APIs.

If you are concerned with differences in the implementations of those
abstract APIs, you need to address them in other organizations (e.g.,
POSIX, etc.).


That seems like a fun task.. (So who is on the list: Apple,
Microsoft, Google(android), Linux, BSD…)

POSIX is maintained by the IEEE, and defines the common API across
various OS implementations - and yes, some of those orgs participate.

That’s far outside the scope of the IETF, though.


That I agree on. The discussion is probably better had over a beer. I do feel 
that it is important that IETF do take into account what is actually used in 
the wild.


...
RFC1122 requires that UDP implementations make the ICMP signals
available to the application. It does not indicate by what mechanism.

Listening for port unreachable can be nice to avoid spamming a host or
application that recently crashed. Detecting fragmentation or max MTU is
also a nice feature especially VoIP applications sending video can
utilise to optimise their packet sizes.

UDP is required to pass ALL ICMP messages to the app layer, as per RFC 1122.

That is another problem. An app using port  will receive all
ICMP messages also generated by other apps running on other ports.

That's an incorrect implementation. See RFC1122 Section 4.1.3.3.

The section says:
UDP MUST pass to the application layer all ICMP error
messages that it receives from the IP layer.  Conceptually
at least, this may be accomplished with an upcall to the
ERROR_REPORT routine (see
Section 4.2.4.1).

Looks like none the implementers do send any ICMP messages to the
UDP layer.

Here's an example of how an app can get errors in response to a call:
http://stackoverflow.com/questions/4888285/send-an-udp-packet-and-receive-an-icmp-response-from-router-in-c

Yes, I cited code example earlier.

The above code does not fly so well unless you have administrative privileges.

I did a series of tests a while back. Code that works on OS-X, Linux and IOS 
can be found here:
https://github.com/palerikm/ICMPTest

Have code for windows as well, but that adds another layer of complexity and 
weirdness.

The app can get async errors (i.e., not in response to a given sendmsg
or recvmsg call) by using a connect() to the socket - i.e., creating a
handle by which the OS can signal the app.

See the book excerpt here:
https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA249&lpg=PA249&dq=socket+errors+icmp&source=bl&ots=Ks3APlbjQs&sig=aBvReFfOYShEGtJtvEheG-