Re: [Taps] TCP components

[Joe Touch]

Hi, Karen,

On 7/16/2015 12:57 AM, Karen Elisabeth Egede Nielsen wrote:
>> What portion of RFC793's API do you consider outdated?

> HI,
> 
> I was thinking about the PUSH flag mainly.
> 
> In our socket api implementation we do not allow for set of PUSH in send
> calls nor do we provide the PUSH flag indication upwards on the receiver
> side.

That's consistent with RFC1122, which updates RFC793.

> I think that after RFC793 it has been clarified that TCP MAY allow for set
> of PUSH flag in send() and MAY OPTIONALLY provide this information upwards
> on the receiver side.

Yes.

> I think that it would be questionable to follow RFC793 wording here on
> PUSH.

Sure; I was being broad in my reference back to RFC793; updates need to
be chased down too, so to the extent that the updates make RFC793
outdated, you're correct. However, the bulk of RFC793's API remains in
effect.

Joe

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

Re: [Taps] TCP components

[Karen Elisabeth Egede Nielsen]

HI,

I was thinking about the PUSH flag mainly.

In our socket api implementation we do not allow for set of PUSH in send
calls nor do we provide the PUSH flag indication upwards on the receiver
side.
I think that after RFC793 it has been clarified that TCP MAY allow for set
of PUSH flag in send() and MAY OPTIONALLY provide this information upwards
on the receiver side.
I think that it would be questionable to follow RFC793 wording here on
PUSH.

I have no much experience with the URGENT flag - we actually don't support
it, which I agree to be non-compliant.
Perhaps the API parts of RFC793 is right, whereas  it is only the function
as such that has been clarified later.

BR, Karen

>-Original Message-
>From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Joe Touch
>Sent: Wednesday, July 15, 2015 8:18 PM
>To: Karen Elisabeth Egede Nielsen; Mirja Kühlewind
>Cc: Brian Trammell; taps@ietf.org; Michael Welzl; to...@isi.edu
>Subject: Re: [Taps] TCP components
>
>
>
>On 7/15/2015 2:03 AM, Karen Elisabeth Egede Nielsen wrote:
>> HI Mirja, All
>>
>> Sorry for jumping late into this discussion.
>...
>> I really do not think that it makes much sense to look into outdated
>> and deprecated APIs as specified in RFC793 and RFC4960 when we have
>> better material available.
>
>What portion of RFC793's API do you consider outdated?
>
>AFAICT, it's exactly what most sockets try to support (I can't speak
about
>SCTP, as I haven't used it much).
>
>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] TCP components

[Joe Touch]

On 7/15/2015 2:03 AM, Karen Elisabeth Egede Nielsen wrote:
> HI Mirja, All
> 
> Sorry for jumping late into this discussion.
...
> I really do not think that it makes much sense to look into outdated and
> deprecated APIs
> as specified in RFC793 and RFC4960 when we have better material available.

What portion of RFC793's API do you consider outdated?

AFAICT, it's exactly what most sockets try to support (I can't speak
about SCTP, as I haven't used it much).

Joe

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

Re: [Taps] TCP components

[Michael Welzl]

> On 15 Jul 2015, at 12:40, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> Hi Michael, All
> 
>> 
>> I have been pointing at RFC6458 but was recently told (and I should have
>> just
>> read the thing instead of being told, sorry  :-() that this RFC does
>> not specify
>> how SCTP's functions are supposed to be exposed to applications using them,
>> but describes one example implementation (in great detail) instead.
>> So, to identify the core functions of the protocol, RFC 4960 is probably a
>> more
>> appropriate source.
>> 
> [Karen ] I both agree and disagree with this statement. My view on this is:
> 
> If looking for an abstract interface I agree that many "implementation"
> details of RFC6458 are unnecessary.
> However a significant number of abstract functions are not described in
> RFC4960 and for control of/API for those
> one need to consult either RFC6458 - or for some of the functions - the api
> section of the RFCs defining these abstract functions.
> 
> I would not know why one should consider only the "core"  services of SCTP
> defined by RFC4960
> as some significant protocol features are only defined by auxiliary RFCs.
> Further there are "core" features defined in RFC4960 for which - used (!) -
> control functions are only exposed in RFC6458.

Okay, sigh  :(   not easy, is it?


> I don't like the API parts of RFC793 as it does not so well represent the
> API of the defacto TCP implementations - not the (very few) I know anyway.
> For example both the sender side and the receiver side handling of PUSH
> flag, which we seem to speak much about here, is not an example of a feature
> where the RFC793 description well represent the implementations.
> Also it obviously cannot well represent newer features, like e.g. control of
> ECN.
> Then, right, ECN may not make it as something we want to expose. Not sure.
> 
> I think that RFC793 and RFC4960 may be good starting points, but saying that
> one will not look beyond them is a misunderstanding. In my view.

I understand


>>> I understand that it is difficult to find out exactly what is the
>>> fundament of TAPS - sometimes it is said that it is the existing IETF
>>> specifications - which means for example that SCTP-CMT and QUIC is
>>> outside of the scope.
>>> Then in other Taps communications - e.g. TCP components - it is said
>>> that one cannot fix the congestion control aspects of TCP as there I
>>> not one CC for TCP - and "one do not know what people implements". I
>>> am not sure exactly what Taps should to do when the defacto standards
>>> (e.g. TCP) have superseded the actual standard. I think that it shall
>>> be on a best judgment basis and when there _are_ specs we should go
>>> with the most recent and sane ones and not with the outdated ones.
>> 
>> One of the very first versions of our charter started the work off with a
>> document that would lay out rules for us, as a basis to make such
>> decisions.
>> I venture to say that I was right to put this document there, and whoever
>> recommended that I should remove it was wrong  :-)because such a
>> document would now be good to have, and I think it's easier to first try to
>> agree on detailed rules (a more fine-grain charter, if you will - which
>> protocols
>> are in scope, how do we decide what a "service" is, etc.) than trying to
>> immediately agree on the actual items themselves (SCTP-CMT: include it or
>> not? Is the Nagle algorithm a service or not?  etc.)
>> 
> [Karen ] Yes. But learning by doing has merits as well. Perhaps one now has
> a more qualified view on what the "rules" should be.

Agreed!

Cheers,
Michael

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

Re: [Taps] TCP components

[Karen Elisabeth Egede Nielsen]

Hi Michael, All

>
>I have been pointing at RFC6458 but was recently told (and I should have
>just
>read the thing instead of being told, sorry  :-() that this RFC does
>not specify
>how SCTP's functions are supposed to be exposed to applications using them,
>but describes one example implementation (in great detail) instead.
>So, to identify the core functions of the protocol, RFC 4960 is probably a
>more
>appropriate source.
>
[Karen ] I both agree and disagree with this statement. My view on this is:

If looking for an abstract interface I agree that many "implementation"
details of RFC6458 are unnecessary.
However a significant number of abstract functions are not described in
RFC4960 and for control of/API for those
one need to consult either RFC6458 - or for some of the functions - the api
section of the RFCs defining these abstract functions.

I would not know why one should consider only the "core"  services of SCTP
defined by RFC4960
as some significant protocol features are only defined by auxiliary RFCs.
Further there are "core" features defined in RFC4960 for which - used (!) -
control functions are only exposed in RFC6458.

I don't like the API parts of RFC793 as it does not so well represent the
API of the defacto TCP implementations - not the (very few) I know anyway.
For example both the sender side and the receiver side handling of PUSH
flag, which we seem to speak much about here, is not an example of a feature
where the RFC793 description well represent the implementations.
Also it obviously cannot well represent newer features, like e.g. control of
ECN.
Then, right, ECN may not make it as something we want to expose. Not sure.

I think that RFC793 and RFC4960 may be good starting points, but saying that
one will not look beyond them is a misunderstanding. In my view.

>
>> I understand that it is difficult to find out exactly what is the
>> fundament of TAPS - sometimes it is said that it is the existing IETF
>> specifications - which means for example that SCTP-CMT and QUIC is
>> outside of the scope.
>> Then in other Taps communications - e.g. TCP components - it is said
>> that one cannot fix the congestion control aspects of TCP as there I
>> not one CC for TCP - and "one do not know what people implements". I
>> am not sure exactly what Taps should to do when the defacto standards
>> (e.g. TCP) have superseded the actual standard. I think that it shall
>> be on a best judgment basis and when there _are_ specs we should go
>> with the most recent and sane ones and not with the outdated ones.
>
>One of the very first versions of our charter started the work off with a
>document that would lay out rules for us, as a basis to make such
>decisions.
>I venture to say that I was right to put this document there, and whoever
>recommended that I should remove it was wrong  :-)because such a
>document would now be good to have, and I think it's easier to first try to
>agree on detailed rules (a more fine-grain charter, if you will - which
>protocols
>are in scope, how do we decide what a "service" is, etc.) than trying to
>immediately agree on the actual items themselves (SCTP-CMT: include it or
>not? Is the Nagle algorithm a service or not?  etc.)
>
[Karen ] Yes. But learning by doing has merits as well. Perhaps one now has
a more qualified view on what the "rules" should be.

BR, Karen

>Cheers,
>Michael

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

Re: [Taps] TCP components

[Michael Welzl]

> On 15 Jul 2015, at 11:03, Karen Elisabeth Egede Nielsen 
>  wrote:
> 
> HI Mirja, All
> 
> Sorry for jumping late into this discussion.
> 
>> -Original Message-
>> From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Mirja Kühlewind
>> Sent: Thursday, June 18, 2015 10:48 AM
>> To: Joe Touch
>> Cc: Brian Trammell; Michael Welzl; taps@ietf.org
>> Subject: Re: [Taps] TCP components
>> 
>> Hi Joe,
>> 
>> I believe the approach Michael is proposing is to look at existing APIs as
>> a
>> starting point; not only abstract APIs. The assumption is that someone who
>> implemented/designed an API, thought that it would be worth to provide a
>> configuration possibility to the higher layer. This assumption is more true
>> for
>> SCTP than for TCP because there are quite a few different TCP
>> implementation that are grown over time. Quite often a new interface was
>> only created because a new feature was added to TCP; and to be on the safe
>> side we allow the user to turn it off again.
>> 
>> That’s the reason why I prefer the approach we are/I'm taking right now
>> (analyzing components). I think we should still describe the abstract API
>> of
>> RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but
>> I
>> personally would not and will not spend too much time analyzing other API.
> 
> [Karen ]
> 
> I really do not think that it makes much sense to look into outdated and
> deprecated APIs
> as specified in RFC793 and RFC4960 when we have better material available.
> For SCTP here specifically RFC6458.
> Personally I cannot support this approach. I am not saying that we need very
> detailed APIs and therefore do not want RFC793 or RFC4960,
> but I want that what we do is based on the right specs (or the right defacto
> implementations) not on known-to-be outdated ones.

I have been pointing at RFC6458 but was recently told (and I should have just 
read the thing instead of being told, sorry  :-() that this RFC does not 
specify how SCTP's functions are supposed to be exposed to applications using 
them, but describes one example implementation (in great detail) instead.
So, to identify the core functions of the protocol, RFC 4960 is probably a more 
appropriate source.


> I understand that it is difficult to find out exactly what is the fundament
> of TAPS - sometimes it is said that
> it is the existing IETF specifications - which means for example that
> SCTP-CMT and QUIC is outside of the scope.
> Then in other Taps communications - e.g. TCP components - it is said that
> one cannot fix the congestion control aspects of TCP as there I not
> one CC for TCP - and "one do not know what people implements". I am not sure
> exactly what Taps should to do when
> the defacto standards (e.g. TCP) have superseded the actual standard. I
> think that it shall be on a best judgment basis and when there _are_ specs
> we should go with the most recent and sane ones and not with the outdated
> ones.

One of the very first versions of our charter started the work off with a 
document that would lay out rules for us, as a basis to make such decisions.
I venture to say that I was right to put this document there, and whoever 
recommended that I should remove it was wrong  :-)because such a document 
would now be good to have, and I think it's easier to first try to agree on 
detailed rules (a more fine-grain charter, if you will - which protocols are in 
scope, how do we decide what a "service" is, etc.) than trying to immediately 
agree on the actual items themselves (SCTP-CMT: include it or not? Is the Nagle 
algorithm a service or not?  etc.)

Cheers,
Michael

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

Re: [Taps] TCP components

[Karen Elisabeth Egede Nielsen]

HI Mirja, All

Sorry for jumping late into this discussion.

>-Original Message-
>From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Mirja Kühlewind
>Sent: Thursday, June 18, 2015 10:48 AM
>To: Joe Touch
>Cc: Brian Trammell; Michael Welzl; taps@ietf.org
>Subject: Re: [Taps] TCP components
>
>Hi Joe,
>
>I believe the approach Michael is proposing is to look at existing APIs as
>a
>starting point; not only abstract APIs. The assumption is that someone who
>implemented/designed an API, thought that it would be worth to provide a
>configuration possibility to the higher layer. This assumption is more true
>for
>SCTP than for TCP because there are quite a few different TCP
>implementation that are grown over time. Quite often a new interface was
>only created because a new feature was added to TCP; and to be on the safe
>side we allow the user to turn it off again.
>
>That’s the reason why I prefer the approach we are/I'm taking right now
>(analyzing components). I think we should still describe the abstract API
>of
>RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but
>I
>personally would not and will not spend too much time analyzing other API.

[Karen ]

I really do not think that it makes much sense to look into outdated and
deprecated APIs
as specified in RFC793 and RFC4960 when we have better material available.
For SCTP here specifically RFC6458.
Personally I cannot support this approach. I am not saying that we need very
detailed APIs and therefore do not want RFC793 or RFC4960,
but I want that what we do is based on the right specs (or the right defacto
implementations) not on known-to-be outdated ones.

I understand that it is difficult to find out exactly what is the fundament
of TAPS - sometimes it is said that
it is the existing IETF specifications - which means for example that
SCTP-CMT and QUIC is outside of the scope.
Then in other Taps communications - e.g. TCP components - it is said that
one cannot fix the congestion control aspects of TCP as there I not
one CC for TCP - and "one do not know what people implements". I am not sure
exactly what Taps should to do when
 the defacto standards (e.g. TCP) have superseded the actual standard. I
think that it shall be on a best judgment basis and when there _are_ specs
we should go with the most recent and sane ones and not with the outdated
ones.

BR, Karen

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

Re: [Taps] TCP components

[Wesley Eddy]

On 6/19/2015 6:55 PM, Joe Touch wrote:
> It's explicit - see section 3.8 of RFC 793. The issue with that variant
> is that it captures the state of TCP in 1981; it has evolved quite a bit
> since then. Although we do have a 793-bis in the works, the update of
> that section hasn't been tackled yet.

I'm not sure that it will be tackled, but we should discuss that on the
TCPM list :).  Since there are no newer RFCs that alter, deprecate, or
replace that API, I don't think we have a good basis to change it in
793bis.

It's still pretty reasonable in my opinion.

-- 
Wes Eddy
MTI Systems

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

Re: [Taps] TCP components

[Joe Touch]

Michael,

On 6/20/2015 1:35 AM, Michael Welzl wrote:



On 20. jun. 2015, at 00.55, Joe Touch  wrote:

On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:

...

Let's put it this way:

- if the goal of TAPS is to unify existing APIs,
then those APIs need to be summarized together in one place


- if TAPS is indeed focused solely on an alternate API,
then it should NOT try to 'restate' the existing TCP API
in a TAPS doc

"Do, or do not; there is no try."
- Yoda


TAPS is focused on an alternate API that it's based on existing
transports. As a way of analyzing existing transports and creating
a foundation for this API, document #1 is written. I think this
discussion is about the approach taken to write document #1.

So now I wonder what you're complaining about,


I'm trying to get Mohamed (and perhaps others) on the same page as you 
and I.


Joe

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

Re: [Taps] TCP components

[Jon Crowcroft]

i dont have any spare time to do it, but maybe someone could have a go at
analyzing all the different TCP offload techniques, which would give
another lens to view this through...

On Sat, Jun 20, 2015 at 9:35 AM, Michael Welzl  wrote:

>
> > On 20. jun. 2015, at 00.55, Joe Touch  wrote:
> >
> >
> >
> > On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
> >>
> >>
> >> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch  >> > wrote:
> >>
> >>
> >>You're getting far ahead of the conversation, IMO. This document
> >>needs to start by explaining the services we already have before
> >>jumping into a "service of services" model.
> >>
> >>I don't disagree with the goal, but it's impractical to develop a
> >>meta-interface when the base interface has not been described.
> >>
> >>
> >> It is just to say that TCP already defines its services, and the goal is
> >> not to give another definition of these services, but only to change the
> >> way they are exposed to applications. So the services definition already
> >> exists, but implicitly.
> >
> > It's explicit - see section 3.8 of RFC 793. The issue with that variant
> is that it captures the state of TCP in 1981; it has evolved quite a bit
> since then. Although we do have a 793-bis in the works, the update of that
> section hasn't been tackled yet.
> >
> > Let's put it this way:
> >
> >   - if the goal of TAPS is to unify existing APIs,
> >   then those APIs need to be summarized together in one place
> >
> >
> >   - if TAPS is indeed focused solely on an alternate API,
> >   then it should NOT try to 'restate' the existing TCP API
> >   in a TAPS doc
> >
> > "Do, or do not; there is no try."
> >   - Yoda
>
> TAPS is focused on an alternate API that it's based on existing
> transports. As a way of analyzing existing transports and creating a
> foundation for this API, document #1 is written. I think this discussion is
> about the approach taken to write document #1.
>
> So now I wonder what you're complaining about, as you go on about TCP
> already defining its services implicitly in the API. I mean, yes it does,
> okay - and so?  You criticized the SCTP API for not being abstract enough -
> so clearly if we'd just copy+paste the API descriptions of the RFCs of the
> considered transports in a list, that would look pretty messy. You seem to
> want a "clean" approach, but you're not going to get that unless we focus
> on TCP alone  :-)
>
> I've been proposing go through transport APIs and then analyze what we
> have, because this way, SCTP is already going to give us a long list of
> services.
> You've been saying that we should start with TCP. Well okay, but the
> service list there is pretty narrow. Maybe the TCP API isn't properly
> described in the current draft, okay, I think we can take that criticism
> for what it is. Still, I don't know what you're really after - in the end,
> we're going to get a list that's pretty similar to what's there now, and
> that's what we want, right?
>
> - unordered reliable delivery of messages
> - delivery of messages with timed delivery
> - reliable delivery of a data stream (naturally that's ordered)
>
>  and so on. Right? Or what else is it you want / expect?
>
> 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] TCP components

[Michael Welzl]

> On 20. jun. 2015, at 00.55, Joe Touch  wrote:
> 
> 
> 
> On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
>> 
>> 
>> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch > > wrote:
>> 
>> 
>>You're getting far ahead of the conversation, IMO. This document
>>needs to start by explaining the services we already have before
>>jumping into a "service of services" model.
>> 
>>I don't disagree with the goal, but it's impractical to develop a
>>meta-interface when the base interface has not been described.
>> 
>> 
>> It is just to say that TCP already defines its services, and the goal is
>> not to give another definition of these services, but only to change the
>> way they are exposed to applications. So the services definition already
>> exists, but implicitly.
> 
> It's explicit - see section 3.8 of RFC 793. The issue with that variant is 
> that it captures the state of TCP in 1981; it has evolved quite a bit since 
> then. Although we do have a 793-bis in the works, the update of that section 
> hasn't been tackled yet.
> 
> Let's put it this way:
> 
>   - if the goal of TAPS is to unify existing APIs,
>   then those APIs need to be summarized together in one place
> 
> 
>   - if TAPS is indeed focused solely on an alternate API,
>   then it should NOT try to 'restate' the existing TCP API
>   in a TAPS doc
> 
> "Do, or do not; there is no try."
>   - Yoda

TAPS is focused on an alternate API that it's based on existing transports. As 
a way of analyzing existing transports and creating a foundation for this API, 
document #1 is written. I think this discussion is about the approach taken to 
write document #1.

So now I wonder what you're complaining about, as you go on about TCP already 
defining its services implicitly in the API. I mean, yes it does, okay - and 
so?  You criticized the SCTP API for not being abstract enough - so clearly if 
we'd just copy+paste the API descriptions of the RFCs of the considered 
transports in a list, that would look pretty messy. You seem to want a "clean" 
approach, but you're not going to get that unless we focus on TCP alone  :-)

I've been proposing go through transport APIs and then analyze what we have, 
because this way, SCTP is already going to give us a long list of services.
You've been saying that we should start with TCP. Well okay, but the service 
list there is pretty narrow. Maybe the TCP API isn't properly described in the 
current draft, okay, I think we can take that criticism for what it is. Still, 
I don't know what you're really after - in the end, we're going to get a list 
that's pretty similar to what's there now, and that's what we want, right?

- unordered reliable delivery of messages
- delivery of messages with timed delivery
- reliable delivery of a data stream (naturally that's ordered)

 and so on. Right? Or what else is it you want / expect? 

Cheers,
Michael

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

Re: [Taps] TCP components

[Joe Touch]

On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:



On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch mailto:to...@isi.edu>> wrote:


You're getting far ahead of the conversation, IMO. This document
needs to start by explaining the services we already have before
jumping into a "service of services" model.

I don't disagree with the goal, but it's impractical to develop a
meta-interface when the base interface has not been described.


It is just to say that TCP already defines its services, and the goal is
not to give another definition of these services, but only to change the
way they are exposed to applications. So the services definition already
exists, but implicitly.


It's explicit - see section 3.8 of RFC 793. The issue with that variant 
is that it captures the state of TCP in 1981; it has evolved quite a bit 
since then. Although we do have a 793-bis in the works, the update of 
that section hasn't been tackled yet.


Let's put it this way:

- if the goal of TAPS is to unify existing APIs,
then those APIs need to be summarized together in one place


- if TAPS is indeed focused solely on an alternate API,
then it should NOT try to 'restate' the existing TCP API
in a TAPS doc

"Do, or do not; there is no try."
- Yoda

Joe

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

Re: [Taps] TCP components

[Mohamed Oulmahdi]

On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch  wrote:

>
> You're getting far ahead of the conversation, IMO. This document needs to
> start by explaining the services we already have before jumping into a
> "service of services" model.
>
> I don't disagree with the goal, but it's impractical to develop a
> meta-interface when the base interface has not been described.


It is just to say that TCP already defines its services, and the goal is
not to give another definition of these services, but only to change the
way they are exposed to applications. So the services definition already
exists, but implicitly.

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

Re: [Taps] TCP components

[Joe Touch]

On 6/19/2015 2:39 PM, Mohamed Oulmahdi wrote:


Of course, no one use a protocol without knowing the service it offers.
When the application requests a TCP connection, it really request a
reliable and ordered connection oriented service. The protocols
primitives are used to each one to offer a part of this service.


My point is that the API primitives do define the service offered in 
this case. You can't use TCP without using OPEN; OPEN exists only 
because TCP is connection-oriented.


Similarly, SEND/RECEIVE are handled in-order and the byte order within 
each call is preserved - which indicates that this is a byte stream 
service. The lack of boundary marking within the SEND/RECEIVE calls - 
and the indication that SEND/RECEIVE block boundaries are not preserved 
- indicates that this is a byte stream service with no internal boundaries.


All of this can be gleaned from the API in section 3.8 of RFC 793.

> The

difficulty occurs when several protocols are available, with mainly a
certain service overlapping.


You're getting far ahead of the conversation, IMO. This document needs 
to start by explaining the services we already have before jumping into 
a "service of services" model.


I don't disagree with the goal, but it's impractical to develop a 
meta-interface when the base interface has not been described.


Joe

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

Re: [Taps] TCP components

[Mohamed Oulmahdi]

On Fri, Jun 19, 2015 at 6:15 PM, Joe Touch  wrote:

>
>
> On 6/19/2015 6:22 AM, Michael Welzl wrote:
> >
> > On 19 Jun 2015, at 14:03, Mirja Kühlewind <
> mirja.kuehlew...@tik.ee.ethz.ch> wrote:
> >> So there current API is always bound to a specify protocol which
> >> already provides you a certain set of service feature. At least in
> >> TCP there is not much choice left and there the current API does
> >> not give us a good indication which services are actually provided
> >> by TCP. Therefore from my point of view the only way to identify
> >> these services is to look at the protocol itself and not only the
> >> API. In SCTP it’s different and we definitely have to and will
> >> discuss the existing API in the document.
> >
> > Exactly that's why I thought starting with TCP's API
> > (even when it's the abstract one) is not very helpful.
> >
> > Joe, Aaron: what is it you were expecting us to take away from
> > reading section 3.8 of RFC 793?
>
> No. IMO, the current description of that API fails to indicate the
> controls *already* available to TCP.
>
> I don't agree that the TCP API doesn't indicate the service TCP provides
> - it's just implicit. E.g.:
>
> OPEN call
> indicates TCP is connection oriented
>
> SEND/RECEIVE calls
> indicates TCP is an ordered byte stream,
> that the user-level byte boundaries are NOT
> related to message boundaries, etc.
>
> Yes, there's some "reading between the lines" to do here.
>


Of course, no one use a protocol without knowing the service it offers.
When the application requests a TCP connection, it really request a
reliable and ordered connection oriented service. The protocols primitives
are used to each one to offer a part of this service. The difficulty occurs
when several protocols are available, with mainly a certain service
overlapping. In this case, exposing Transport services by the protocols
offering them is not convenient to applications developers because they
must be aware of the several protocols details that are not always evident
to some of them. The objective is so simply to change this service
exposition from a protocol-based to a service-based, allowing developers to
request services without knowing anything about the underlying protocols
offering these services.


>
> > ( I can see it highlighting the need
> > to discuss communication patterns (or decide for a specific one) in
> > document #2, but not really contributing much to the list in document
> > #1 ? )
>
> I believe the opposite is true.
>
> 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] TCP components

[Joe Touch]

On 6/19/2015 6:22 AM, Michael Welzl wrote:
>
> On 19 Jun 2015, at 14:03, Mirja Kühlewind  
> wrote:
>> So there current API is always bound to a specify protocol which
>> already provides you a certain set of service feature. At least in
>> TCP there is not much choice left and there the current API does
>> not give us a good indication which services are actually provided
>> by TCP. Therefore from my point of view the only way to identify
>> these services is to look at the protocol itself and not only the
>> API. In SCTP it’s different and we definitely have to and will
>> discuss the existing API in the document.
>
> Exactly that's why I thought starting with TCP's API 
> (even when it's the abstract one) is not very helpful.
>
> Joe, Aaron: what is it you were expecting us to take away from 
> reading section 3.8 of RFC 793?

No. IMO, the current description of that API fails to indicate the
controls *already* available to TCP.

I don't agree that the TCP API doesn't indicate the service TCP provides
- it's just implicit. E.g.:

OPEN call
indicates TCP is connection oriented

SEND/RECEIVE calls
indicates TCP is an ordered byte stream,
that the user-level byte boundaries are NOT
related to message boundaries, etc.

Yes, there's some "reading between the lines" to do here.

> ( I can see it highlighting the need
> to discuss communication patterns (or decide for a specific one) in
> document #2, but not really contributing much to the list in document
> #1 ? )

I believe the opposite is true.

Joe

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

Re: [Taps] TCP components

[Joe Touch]

On 6/19/2015 7:15 AM, Mirja Kühlewind wrote:
> Cool! I think that the alternative approach Brian just proposed:
> Start with the feature we think/know we want to have and the compare
> them with what we have in the first document.

-1

If you don't know what you already have, it's hard to figure out why
what you need isn't there.

Joe

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

Re: [Taps] TCP components

[Mirja Kühlewind]

Hi Michael,

> 
>> Again, if you have time to work on an alternative approach, please go ahead 
>> and provide input or even submit an own draft and I’m/we’re really open to 
>> discuss this and see what makes more sense. 
> 
> Ok  well, I agree that what I request is easier said than done  :-( 
> myself, I've been working on a first version of document #2 as I think this 
> would help us understand if the set of "services" or whatever we call them in 
> document #1 is useful for the group's purpose.

Cool! I think that the alternative approach Brian just proposed: Start with the 
feature we think/know we want to have and the compare them with what we have in 
the first document.

Mirja

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

Re: [Taps] TCP components

[Michael Welzl]

> On 19 Jun 2015, at 14:32, Brian Trammell  wrote:
> 
> hi Michael,
> 
> continued, inline.
> 
>> On 18 Jun 2015, at 18:44, Michael Welzl  wrote:
>> 
>> 
>>> On 18. jun. 2015, at 15.56, Mirja Kühlewind 
>>>  wrote:
>>> 
>>> Hi Michael,
>>> 
 Am 18.06.2015 um 15:43 schrieb Michael Welzl :
 
 
> On 18 Jun 2015, at 10:48, Mirja Kühlewind 
>  wrote:
> 
> Hi Joe,
> 
> I believe the approach Michael is proposing is to look at existing APIs 
> as a starting point; not only abstract APIs.
 
 No, wrong. Only abstract ones from RFCs, I said this before. These things 
 would typically have preceding IETF debate, whereas trying to cover 
 implementations is a huge and probably meaningless endeavour (the bar may 
 be high for adding function calls to an API on system X and low for an API 
 on system Y).
>>> 
>>> Okay, but then I don’t really understand your approach fully. Yes we should 
>>> document and look at what’s already specified in RFC, however isn’t the 
>>> goal of taps to actually figure out how to change/extend/improve these 
>>> APIs? How can we figure out what’s missing/wrong if we only look at what’s 
>>> already there?
>> 
>> *My* goal is, and has always been, to provide a simpler, general API that is 
>> protocol independent.
> 
> +1, though I would at this point say "better" as opposed to "simpler" and 
> "general", with the caveat that i'm not yet sure what better looks like. This 
> gets back to my point about interaction patterns in the previous message, 
> though: if the simpler API provides only stream interaction, or packet 
> sequence interaction, or if it only allows receivers to get data through 
> asynchronous notifications, it will make it hard to support . So maybe we 
> want a better common API for defining the *requirements* of an association, 
> and better TX/RX *APIs* plural, one for each interaction pattern we want to 
> support.

I agree.


>> Note that this is not only for simplicity for ease of use BUT also for the 
>> sake of being able to automatize. After all the major goal is to remove the 
>> strict binding between applications and a specific protocol choice.
> 
> We share this higher level goal in any case.
> 
>> To be able to do this (documents 2 and 3), we first need a list of the 
>> existing services - our toolbox, if you wish (document 1). Figuring out 
>> what's missing / wrong about today's APIs (except that they are bound to a 
>> specific protocol) has never been *my* major intention, and I certainly 
>> don't see that as the goal of this document. I'd be surprised if that's what 
>> the charter suggests?! But of course my opinion is only what it is, the 
>> charter reflects the consensus...
> 
> I don't think that's in scope for this document, either. The component (and 
> decomposition) work is aimed at figuring out what the available features are, 
> and what (in a "TAPS as glue layer over existing transports" design) the 
> implications of using protocol X for feature Y are. The API work is a bit of 
> a non-sequitur (but also important to note...)
> 
>> All this being said, it can be a nice side-effect of the document (and note 
>> that noone knows what a TAPS system will really look like, and how these 
>> RFCs will actually end up being used).
> 
> In general, if there's any content in this document that is useful but 
> doesn't fit but we still find useful, we can certainly put it something else.
> 
>> So I'm not strongly opposing the approach you're now following in that I 
>> don't see a big issue with there being a list of components - I just think 
>> it's not particularly useful for the goal of the document and doesn't really 
>> help the group progress towards its goals. I thought that proposing 
>> something more systematic with less arbitrariness could make it easier to 
>> put everyone in the same boat (in a way: "look, the boat HAS to be like 
>> that, there wasn't much choice, sit down please" rather than "sorry I 
>> painted it green, I like that color; I can understand you would have 
>> preferred a blue boat...").
> 
> I agree. Given, though, that the protocols we're looking at, that they 
> weren't designed from components, it is really not clear to me how to 
> systematically decompose existing protocols without making arbitrary choices 
> as to where to make the cut.

but why decompose?


> (and I wouldn't read too much into the approach we're following -- we're 
> trying to incorporate the input we've taken from discussion on the list into 
> the structure of the document, and as Mirja says, we're completely open to 
> trying other approaches to do that).
> 
> We could take an opposite approach here: jump forward to section 4, define 
> the features we think we want -- this we can do more systematically, because 
> we're only limited by the intersection of the features we want and the 
> features we think we can realistically deploy, as opposed to the history 
> represented by 

Re: [Taps] TCP components

[Michael Welzl]

> On 19 Jun 2015, at 14:03, Mirja Kühlewind  
> wrote:
> 
> Hi Michael,
> 
>> *My* goal is, and has always been, to provide a simpler, general API that is 
>> protocol independent. Note that this is not only for simplicity for ease of 
>> use BUT also for the sake of being able to automatize. After all the major 
>> goal is to remove the strict binding between applications and a specific 
>> protocol choice.
> 
> Yes, I agree! (not sure if this is simpler though… depends on the definition 
> of simple… but hopefully easier to use and understand for the overlying 
> application).

Agree too, easier to use is what I meant


>> To be able to do this (documents 2 and 3), we first need a list of the 
>> existing services - our toolbox, if you wish (document 1). Figuring out 
>> what's missing / wrong about today's APIs (except that they are bound to a 
>> specific protocol) has never been *my* major intention, and I certainly 
>> don't see that as the goal of this document. I'd be surprised if that's what 
>> the charter suggests?! But of course my opinion is only what it is, the 
>> charter reflects the consensus…
> 
> So there current API is always bound to a specify protocol which already 
> provides you a certain set of service feature. At least in TCP there is not 
> much choice left and there the current API does not give us a good indication 
> which services are actually provided by TCP. Therefore from my point of view 
> the only way to identify these services is to look at the protocol itself and 
> not only the API. In SCTP it’s different and we definitely have to and will 
> discuss the existing API in the document.

Exactly that's why I thought starting with TCP's API (even when it's the 
abstract one) is not very helpful.
Joe, Aaron: what is it you were expecting us to take away from reading section 
3.8 of RFC 793?
( I can see it highlighting the need to discuss communication patterns  (or 
decide for a specific one) in document #2, but not really contributing much to 
the list in document #1 ? )


>> All this being said, it can be a nice side-effect of the document (and note 
>> that noone knows what a TAPS system will really look like, and how these 
>> RFCs will actually end up being used). So I'm not strongly opposing the 
>> approach you're now following in that I don't see a big issue with there 
>> being a list of components - I just think it's not particularly useful for 
>> the goal of the document and doesn't really help the group progress towards 
>> its goals. I thought that proposing something more systematic with less 
>> arbitrariness could make it easier to put everyone in the same boat (in a 
>> way: "look, the boat HAS to be like that, there wasn't much choice, sit down 
>> please" rather than "sorry I painted it green, I like that color; I can 
>> understand you would have preferred a blue boat...“).
> 
> I totally understand this point. But at least for TCP I think it is not 
> sufficient to look at the (abstract) API because in TCP there are not much 
> choices and therefore the services TCP provides are not exposed over the API. 
> I personally currently don’t see how another approach would bring us the the 
> goal of identify existing services.

Agree about TCP


> Again, if you have time to work on an alternative approach, please go ahead 
> and provide input or even submit an own draft and I’m/we’re really open to 
> discuss this and see what makes more sense. 

Ok  well, I agree that what I request is easier said than done  :-( 
myself, I've been working on a first version of document #2 as I think this 
would help us understand if the set of "services" or whatever we call them in 
document #1 is useful for the group's purpose.

Michael

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

Re: [Taps] TCP components

[Brian Trammell]

hi Michael,

continued, inline.

> On 18 Jun 2015, at 18:44, Michael Welzl  wrote:
> 
> 
>> On 18. jun. 2015, at 15.56, Mirja Kühlewind 
>>  wrote:
>> 
>> Hi Michael,
>> 
>>> Am 18.06.2015 um 15:43 schrieb Michael Welzl :
>>> 
>>> 
 On 18 Jun 2015, at 10:48, Mirja Kühlewind 
  wrote:
 
 Hi Joe,
 
 I believe the approach Michael is proposing is to look at existing APIs as 
 a starting point; not only abstract APIs.
>>> 
>>> No, wrong. Only abstract ones from RFCs, I said this before. These things 
>>> would typically have preceding IETF debate, whereas trying to cover 
>>> implementations is a huge and probably meaningless endeavour (the bar may 
>>> be high for adding function calls to an API on system X and low for an API 
>>> on system Y).
>> 
>> Okay, but then I don’t really understand your approach fully. Yes we should 
>> document and look at what’s already specified in RFC, however isn’t the goal 
>> of taps to actually figure out how to change/extend/improve these APIs? How 
>> can we figure out what’s missing/wrong if we only look at what’s already 
>> there?
> 
> *My* goal is, and has always been, to provide a simpler, general API that is 
> protocol independent.

+1, though I would at this point say "better" as opposed to "simpler" and 
"general", with the caveat that i'm not yet sure what better looks like. This 
gets back to my point about interaction patterns in the previous message, 
though: if the simpler API provides only stream interaction, or packet sequence 
interaction, or if it only allows receivers to get data through asynchronous 
notifications, it will make it hard to support . So maybe we want a better 
common API for defining the *requirements* of an association, and better TX/RX 
*APIs* plural, one for each interaction pattern we want to support.

> Note that this is not only for simplicity for ease of use BUT also for the 
> sake of being able to automatize. After all the major goal is to remove the 
> strict binding between applications and a specific protocol choice.

We share this higher level goal in any case.

> To be able to do this (documents 2 and 3), we first need a list of the 
> existing services - our toolbox, if you wish (document 1). Figuring out 
> what's missing / wrong about today's APIs (except that they are bound to a 
> specific protocol) has never been *my* major intention, and I certainly don't 
> see that as the goal of this document. I'd be surprised if that's what the 
> charter suggests?! But of course my opinion is only what it is, the charter 
> reflects the consensus...

I don't think that's in scope for this document, either. The component (and 
decomposition) work is aimed at figuring out what the available features are, 
and what (in a "TAPS as glue layer over existing transports" design) the 
implications of using protocol X for feature Y are. The API work is a bit of a 
non-sequitur (but also important to note...)

> All this being said, it can be a nice side-effect of the document (and note 
> that noone knows what a TAPS system will really look like, and how these RFCs 
> will actually end up being used).

In general, if there's any content in this document that is useful but doesn't 
fit but we still find useful, we can certainly put it something else.

> So I'm not strongly opposing the approach you're now following in that I 
> don't see a big issue with there being a list of components - I just think 
> it's not particularly useful for the goal of the document and doesn't really 
> help the group progress towards its goals. I thought that proposing something 
> more systematic with less arbitrariness could make it easier to put everyone 
> in the same boat (in a way: "look, the boat HAS to be like that, there wasn't 
> much choice, sit down please" rather than "sorry I painted it green, I like 
> that color; I can understand you would have preferred a blue boat...").

I agree. Given, though, that the protocols we're looking at, that they weren't 
designed from components, it is really not clear to me how to systematically 
decompose existing protocols without making arbitrary choices as to where to 
make the cut. (and I wouldn't read too much into the approach we're following 
-- we're trying to incorporate the input we've taken from discussion on the 
list into the structure of the document, and as Mirja says, we're completely 
open to trying other approaches to do that).

We could take an opposite approach here: jump forward to section 4, define the 
features we think we want -- this we can do more systematically, because we're 
only limited by the intersection of the features we want and the features we 
think we can realistically deploy, as opposed to the history represented by the 
protocol components -- and then use the components as a check on the 
feasibility of those features.

Cheers,

Brian



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Taps] TCP components

[Mirja Kühlewind]

Hi Michael,

> *My* goal is, and has always been, to provide a simpler, general API that is 
> protocol independent. Note that this is not only for simplicity for ease of 
> use BUT also for the sake of being able to automatize. After all the major 
> goal is to remove the strict binding between applications and a specific 
> protocol choice.

Yes, I agree! (not sure if this is simpler though… depends on the definition of 
simple… but hopefully easier to use and understand for the overlying 
application).

> 
> To be able to do this (documents 2 and 3), we first need a list of the 
> existing services - our toolbox, if you wish (document 1). Figuring out 
> what's missing / wrong about today's APIs (except that they are bound to a 
> specific protocol) has never been *my* major intention, and I certainly don't 
> see that as the goal of this document. I'd be surprised if that's what the 
> charter suggests?! But of course my opinion is only what it is, the charter 
> reflects the consensus…

So there current API is always bound to a specify protocol which already 
provides you a certain set of service feature. At least in TCP there is not 
much choice left and there the current API does not give us a good indication 
which services are actually provided by TCP. Therefore from my point of view 
the only way to identify these services is to look at the protocol itself and 
not only the API. In SCTP it’s different and we definitely have to and will 
discuss the existing API in the document.

> 
> All this being said, it can be a nice side-effect of the document (and note 
> that noone knows what a TAPS system will really look like, and how these RFCs 
> will actually end up being used). So I'm not strongly opposing the approach 
> you're now following in that I don't see a big issue with there being a list 
> of components - I just think it's not particularly useful for the goal of the 
> document and doesn't really help the group progress towards its goals. I 
> thought that proposing something more systematic with less arbitrariness 
> could make it easier to put everyone in the same boat (in a way: "look, the 
> boat HAS to be like that, there wasn't much choice, sit down please" rather 
> than "sorry I painted it green, I like that color; I can understand you would 
> have preferred a blue boat...“).

I totally understand this point. But at least for TCP I think it is not 
sufficient to look at the (abstract) API because in TCP there are not much 
choices and therefore the services TCP provides are not exposed over the API. I 
personally currently don’t see how another approach would bring us the the goal 
of identify existing services.

Again, if you have time to work on an alternative approach, please go ahead and 
provide input or even submit an own draft and I’m/we’re really open to discuss 
this and see what makes more sense. 

Mirja



> 
> Cheers,
> Michael

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

Re: [Taps] TCP components

[Michael Welzl]

> On 19 Jun 2015, at 12:07, Brian Trammell  wrote:
> 
> hi Michael,
> 
> A few replies inline.
> 
>> On 18 Jun 2015, at 15:54, Michael Welzl  wrote:
>> 
>> 
>>> On 17 Jun 2015, at 12:13, Brian Trammell  wrote:
>>> 
>>> hi Michael, all,
>>> 
>>> A couple of random points inline at various levels of quotation...
>>> 
 On 17 Jun 2015, at 10:44, Michael Welzl  wrote:
 
>> 
>> I agree that the list below is closer to what I think a "component" 
>> should be ... but looking at it, is it not even clearer now that 
>> components are not what TAPS is after? To me this list now contains lots 
>> and lots of details that are irrelevant to the service provided to the 
>> application.
>>> 
>>> That's part of the point we're trying to address here. The realization we 
>>> had here is that components *don't* necessarily map to feature, and it's 
>>> not clear that we can simply ignore those components that don't map, since 
>>> they may have impact on the interfaces/features it is possible to 
>>> (reasonably) implement atop those protocols.
>>> 
>> Not harmful to list but pretty useless?!
>>> 
>>> Let's start with TCP as probably the most difficult example (indeed, that's 
>>> why we worked out this "new" arrangement of components for TCP first). A 
>>> completely clean and unambiguous decomposition of TCP into its features -- 
>>> what, I agree, we're after in the end -- is not *really* possible, because 
>>> the protocols as defined and implemented weren't really composed of 
>>> discrete features. The evolution of loss-based congestion control, for 
>>> instance, was predicated on the particular loss signals that were available 
>>> at the time it was first defined. The error detection mechanism likewise 
>>> relies on the fact that reliability is provided by retransmission. One 
>>> could say that given the parallel evolution of computing power that all 
>>> these choices made by TCP were the only obvious ones at the time. But it's 
>>> precisely the co-evolution of reliability and congestion control that makes 
>>> gluing FEC to TCP so fraught with peril. That's an important point to 
>>> capture IMO.
>>> 
>>> I expect that the same exercise for SCTP will show a simpler mapping 
>>> between components and features, since it *was* designed as a composition 
>>> of features.
>> 
>> I expect that too, but I still don't understand the point of the component 
>> list above. I mean, yes, you may be able to map and say "we need components 
>> X Y Z to provide features A and B" but how does this help TAPS?
> 
> So as I see it, "features" are the TAPS view of the world of the future -- 
> the set of things that transport protocols can do, and that a better 
> interface can give you access to. "Components" are the view of the world of 
> the present -- what the current definitions *and deployed implementations* of 
> transport protocols can do, and what each of those features imply.
> 
> There are a few ways you can implement the TAPS API. The one we chose to 
> pursue in the WG (or at least I thought we had) is that the TAPS API takes 
> (1) information from the application about its requirements in terms of 
> features and parameters on those features (if available), (2) information 
> from the path about which transport protocols and options are usable on the 
> path, and the selects a transport protocol, and acts as glue between the API 
> and the underlying protocol.
> 
> In this approach, it is IMO important to catalog the protocol components (and 
> the interactions among them) since the mappings between components and 
> features might not be clean. This might not be the document to do that in. 
> But we wanted to do the exercise to see what the outcome looked like.

I see. Well I don't have a problem with that, I was just suggesting that this 
is probably not the path of easy agreement.


> 
> 
> However, you could go for a even more generic approach and only look at 
> the implementation and as a first step figure where are any knobs that in 
> principle could be configurable and then afterwards discuss all of these 
> very specific knobs. I though about this approach and think it would be 
> an interest exercise and potentially the right way to go. But I also 
> think that the overhead would be super large and I don’t think it would 
> give us much more than we have right now. So we the current approach we 
> might need to expect some arbitrariness…
 
 I lean towards this other one, of beginning with the knobs,
>>> 
>>> ... understanding that interface definitions aren't just about which knobs 
>>> (and indicators) the API provides, but also the interaction patterns it 
>>> enables, and that these interaction patterns can also be made inefficient 
>>> or even impractical by the details of the protocol in question. (It's 
>>> always *possible* to implement object transfer over streams, or time domain 
>>> transfer over objects, or to trans

Re: [Taps] TCP components

[Brian Trammell]

hi Michael,

A few replies inline.

> On 18 Jun 2015, at 15:54, Michael Welzl  wrote:
> 
> 
>> On 17 Jun 2015, at 12:13, Brian Trammell  wrote:
>> 
>> hi Michael, all,
>> 
>> A couple of random points inline at various levels of quotation...
>> 
>>> On 17 Jun 2015, at 10:44, Michael Welzl  wrote:
>>> 
> 
> I agree that the list below is closer to what I think a "component" 
> should be ... but looking at it, is it not even clearer now that 
> components are not what TAPS is after? To me this list now contains lots 
> and lots of details that are irrelevant to the service provided to the 
> application.
>> 
>> That's part of the point we're trying to address here. The realization we 
>> had here is that components *don't* necessarily map to feature, and it's not 
>> clear that we can simply ignore those components that don't map, since they 
>> may have impact on the interfaces/features it is possible to (reasonably) 
>> implement atop those protocols.
>> 
> Not harmful to list but pretty useless?!
>> 
>> Let's start with TCP as probably the most difficult example (indeed, that's 
>> why we worked out this "new" arrangement of components for TCP first). A 
>> completely clean and unambiguous decomposition of TCP into its features -- 
>> what, I agree, we're after in the end -- is not *really* possible, because 
>> the protocols as defined and implemented weren't really composed of discrete 
>> features. The evolution of loss-based congestion control, for instance, was 
>> predicated on the particular loss signals that were available at the time it 
>> was first defined. The error detection mechanism likewise relies on the fact 
>> that reliability is provided by retransmission. One could say that given the 
>> parallel evolution of computing power that all these choices made by TCP 
>> were the only obvious ones at the time. But it's precisely the co-evolution 
>> of reliability and congestion control that makes gluing FEC to TCP so 
>> fraught with peril. That's an important point to capture IMO.
>> 
>> I expect that the same exercise for SCTP will show a simpler mapping between 
>> components and features, since it *was* designed as a composition of 
>> features.
> 
> I expect that too, but I still don't understand the point of the component 
> list above. I mean, yes, you may be able to map and say "we need components X 
> Y Z to provide features A and B" but how does this help TAPS?

So as I see it, "features" are the TAPS view of the world of the future -- the 
set of things that transport protocols can do, and that a better interface can 
give you access to. "Components" are the view of the world of the present -- 
what the current definitions *and deployed implementations* of transport 
protocols can do, and what each of those features imply.

There are a few ways you can implement the TAPS API. The one we chose to pursue 
in the WG (or at least I thought we had) is that the TAPS API takes (1) 
information from the application about its requirements in terms of features 
and parameters on those features (if available), (2) information from the path 
about which transport protocols and options are usable on the path, and the 
selects a transport protocol, and acts as glue between the API and the 
underlying protocol.

In this approach, it is IMO important to catalog the protocol components (and 
the interactions among them) since the mappings between components and features 
might not be clean. This might not be the document to do that in. But we wanted 
to do the exercise to see what the outcome looked like.



 However, you could go for a even more generic approach and only look at 
 the implementation and as a first step figure where are any knobs that in 
 principle could be configurable and then afterwards discuss all of these 
 very specific knobs. I though about this approach and think it would be an 
 interest exercise and potentially the right way to go. But I also think 
 that the overhead would be super large and I don’t think it would give us 
 much more than we have right now. So we the current approach we might need 
 to expect some arbitrariness…
>>> 
>>> I lean towards this other one, of beginning with the knobs,
>> 
>> ... understanding that interface definitions aren't just about which knobs 
>> (and indicators) the API provides, but also the interaction patterns it 
>> enables, and that these interaction patterns can also be made inefficient or 
>> even impractical by the details of the protocol in question. (It's always 
>> *possible* to implement object transfer over streams, or time domain 
>> transfer over objects, or to translate asynchonous events into a synchronous 
>> API. That the Web and video thereon "work" is proof of that. You can run the 
>> whole Internet over DNS, if you want to. It would not work as well as the 
>> one we have today. :) )
> 
> Yes, I agree, and I hope that this won't really bite us... or wh

Re: [Taps] TCP components

[Joe Touch]

+1

On 6/18/2015 9:44 AM, Michael Welzl wrote:

*My*  goal is, and has always been, to provide a simpler, general API
that is protocol independent. Note that this is not only for
simplicity for ease of use BUT also for the sake of being able to
automatize. After all the major goal is to remove the strict binding
between applications and a specific protocol choice.

To be able to do this (documents 2 and 3), we first need a list of
the existing services - our toolbox, if you wish (document 1).
Figuring out what's missing / wrong about today's APIs (except that
they are bound to a specific protocol) has never been*my*  major
intention, and I certainly don't see that as the goal of this
document. I'd be surprised if that's what the charter suggests?! But
of course my opinion is only what it is, the charter reflects the
consensus...


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

Re: [Taps] TCP components

[Michael Welzl]

> On 18. jun. 2015, at 15.56, Mirja Kühlewind  
> wrote:
> 
> Hi Michael,
> 
>> Am 18.06.2015 um 15:43 schrieb Michael Welzl :
>> 
>> 
>>> On 18 Jun 2015, at 10:48, Mirja Kühlewind  
>>> wrote:
>>> 
>>> Hi Joe,
>>> 
>>> I believe the approach Michael is proposing is to look at existing APIs as 
>>> a starting point; not only abstract APIs.
>> 
>> No, wrong. Only abstract ones from RFCs, I said this before. These things 
>> would typically have preceding IETF debate, whereas trying to cover 
>> implementations is a huge and probably meaningless endeavour (the bar may be 
>> high for adding function calls to an API on system X and low for an API on 
>> system Y).
> 
> Okay, but then I don’t really understand your approach fully. Yes we should 
> document and look at what’s already specified in RFC, however isn’t the goal 
> of taps to actually figure out how to change/extend/improve these APIs? How 
> can we figure out what’s missing/wrong if we only look at what’s already 
> there?

*My* goal is, and has always been, to provide a simpler, general API that is 
protocol independent. Note that this is not only for simplicity for ease of use 
BUT also for the sake of being able to automatize. After all the major goal is 
to remove the strict binding between applications and a specific protocol 
choice.

To be able to do this (documents 2 and 3), we first need a list of the existing 
services - our toolbox, if you wish (document 1). Figuring out what's missing / 
wrong about today's APIs (except that they are bound to a specific protocol) 
has never been *my* major intention, and I certainly don't see that as the goal 
of this document. I'd be surprised if that's what the charter suggests?! But of 
course my opinion is only what it is, the charter reflects the consensus...

All this being said, it can be a nice side-effect of the document (and note 
that noone knows what a TAPS system will really look like, and how these RFCs 
will actually end up being used). So I'm not strongly opposing the approach 
you're now following in that I don't see a big issue with there being a list of 
components - I just think it's not particularly useful for the goal of the 
document and doesn't really help the group progress towards its goals. I 
thought that proposing something more systematic with less arbitrariness could 
make it easier to put everyone in the same boat (in a way: "look, the boat HAS 
to be like that, there wasn't much choice, sit down please" rather than "sorry 
I painted it green, I like that color; I can understand you would have 
preferred a blue boat...").

Cheers,
Michael

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

Re: [Taps] TCP components

[Mirja Kühlewind]

Hi Michael,

> Am 18.06.2015 um 15:43 schrieb Michael Welzl :
> 
> 
>> On 18 Jun 2015, at 10:48, Mirja Kühlewind  
>> wrote:
>> 
>> Hi Joe,
>> 
>> I believe the approach Michael is proposing is to look at existing APIs as a 
>> starting point; not only abstract APIs.
> 
> No, wrong. Only abstract ones from RFCs, I said this before. These things 
> would typically have preceding IETF debate, whereas trying to cover 
> implementations is a huge and probably meaningless endeavour (the bar may be 
> high for adding function calls to an API on system X and low for an API on 
> system Y).

Okay, but then I don’t really understand your approach fully. Yes we should 
document and look at what’s already specified in RFC, however isn’t the goal of 
taps to actually figure out how to change/extend/improve these APIs? How can we 
figure out what’s missing/wrong if we only look at what’s already there?

Mirja

> 
> 
>> The assumption is that someone who implemented/designed an API, thought that 
>> it would be worth to provide a configuration possibility to the higher 
>> layer. This assumption is more true for SCTP than for TCP because there are 
>> quite a few different TCP implementation that are grown over time. Quite 
>> often a new interface was only created because a new feature was added to 
>> TCP; and to be on the safe side we allow the user to turn it off again.
>> 
>> That’s the reason why I prefer the approach we are/I'm taking right now 
>> (analyzing components). I think we should still describe the abstract API of 
>> RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but 
>> I personally would not and will not spend too much time analyzing other API. 
>> However, everybody who has time and is interested in this can of course 
>> provide his/her outcome as input for this document and we will happily take 
>> it and compare it to what we have so far.
> 
> But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), not 
> implementations out there.
> 
> More below, answering Joe  (hm, that rhymes ;-)  ) -
> 
> 
>> 
>> Mirja
>> 
>> 
>>> Am 17.06.2015 um 20:10 schrieb Joe Touch :
>>> 
>>> 
>>> 
>>> On 6/17/2015 1:44 AM, Michael Welzl wrote:
 I think that this discussion with Joe maybe suffered from focusing on
 TCP. 
>>> 
>>> To be fair, TCP has a simpler abstract API.
>>> 
 SCTP is perhaps a better starting point because it supports
 almost everything. 
>>> 
>>> IMO, that makes it very hard as a starting point, and I also think that
>>> TCP's variant of an API description is much better as an example.
>>> 
>>> E.g., Section 10 of RFC4960 claims it defines an abstract API
>>> (ULP-to_SCTP), but it begins by describing a call to initialize a data
>>> structure (INITIALIZE). That's decidedly NOT an abstract API; it's a
>>> generic description of an implementation issue.
>>> 
>>> IMO, if we don't understand the difference between the API in RFC793 vs.
>>> that in RFC4960 (and why 793 is a better example), then this is going to
>>> be a very bumpy road.
> 
> How abstract it is in the RFC indeed isn't my main concern here: it's to 
> start with the interface (however abstract it is) offered to applications as 
> described in the RFCs, as this reflects what the designers (with some level 
> of IETF consensus) thought should be exposed.
> Now, of course SCTP has more options and is more complex in its usage than 
> TCP, but it covers a larger part of the space of services in protocols - so I 
> thought it's a good starting point, as in: 80% done by looking at 1 protocol, 
> check the others for the remaining 20%. Something like that.
> 
> This is just me being pragmatic and trying to have a more systematic approach 
> to developing a list of services. I agree with Brian that some level of 
> arbitrariness will always be there, but we must try to minimize it I think.
> 
> Cheers,
> Michael

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

Re: [Taps] TCP components

[Michael Welzl]

> On 17 Jun 2015, at 12:13, Brian Trammell  wrote:
> 
> hi Michael, all,
> 
> A couple of random points inline at various levels of quotation...
> 
>> On 17 Jun 2015, at 10:44, Michael Welzl  wrote:
>> 
>> 
>> On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind 
>>  wrote:
>> 
>>> Hi Michael,
>>> 
>>> see below.
>>> 
 Am 17.06.2015 um 09:36 schrieb Michael Welzl :
 
 Hi,
 
 
> On 11 Jun 2015, at 13:52, Mirja Kühlewind 
>  wrote:
> 
> Hi all,
> 
> we gave it a first try to rewrite the component section for TCP. The 
> insight I took from the discussion on the list is that components 
> probably are much more linked to the implementation (choices) a certain 
> protocol made while features are probably more high-level having the 
> question in mind what does an application potentially want/need to know.
> 
> So for the components in TCP we now have the following list:
> 
> - Connection-oriented bidirectional communication using three-way 
> handshake connection setup with
>   feature negotiation and an explicit distinction between passive and 
> active open:
>   This implies both unicast addressing and a guarantee of return 
> routability.
> - Single stream-oriented transmission:
>   The stream abstraction atop the datagram service provided by IP is 
> implemented by dividing
>   the stream into segments.
> - Limited control over segment transmission scheduling (Nagle's 
> algorithm):
>   This allows for delay minimization in interactive applications.
> - Port multiplexing, with application-to-port mapping during connection 
> setup:
>   Note that in the presence of network address and port translation 
> (NAPT), TCP ports are
>   in effect part of the endpoint address for forwarding purposes.
> - Full reliability based on ack-based loss detection and retransmission:
>   Loss is sensed using duplicated acks ("fast retransmit"), which places 
> a lower bound on
>   the delay inherent in this approach to reliability.
> - Error detection based on a checksum covering the network and transport 
> headers as well as payload:
>   Packets that are detected as corrupted are dropped, relying on the 
> reliability mechanism
>   to retransmit them.
> - Window-based flow control, with receiver-side window management and 
> signaling of available window:
>   Scaling the flow control window beyond 64kB requires the use of an 
> optional feature,
>   which has performance implications in environments where this option is 
> not supported.
> - Window-based congestion control reacting to loss, delay, retransmission 
> timeout, or
>   an explicit congestion signal (ECN):
>   Most commonly used is a loss signal from the reliability component's 
> retransmission mechanism.
>   TCP reacts to a congestion signal by reducing the size of the 
> congestion window;
>   retransmission timeout is generally handled with a larger reaction than 
> other signals.
> 
> We are currently still working on the list of features that results from 
> thiese components but we are not there yet. Probably we not only need the 
> features itself but also properties/aspects (or however you want to call 
> this) of the feature. We already had this discussion a bit but wanted to 
> postpone the decision if we really need to define an own term for this 
> until we are sure that we need it.
> 
> We are posting this list of (TCP) components now because we would like to 
> get some feedback if this goes into the right direction/is on the right 
> level of detail before we go on and apply this also to other protocols.
 
 I agree that the list below is closer to what I think a "component" should 
 be ... but looking at it, is it not even clearer now that components are 
 not what TAPS is after? To me this list now contains lots and lots of 
 details that are irrelevant to the service provided to the application.
> 
> That's part of the point we're trying to address here. The realization we had 
> here is that components *don't* necessarily map to feature, and it's not 
> clear that we can simply ignore those components that don't map, since they 
> may have impact on the interfaces/features it is possible to (reasonably) 
> implement atop those protocols.
> 
 Not harmful to list but pretty useless?!
> 
> Let's start with TCP as probably the most difficult example (indeed, that's 
> why we worked out this "new" arrangement of components for TCP first). A 
> completely clean and unambiguous decomposition of TCP into its features -- 
> what, I agree, we're after in the end -- is not *really* possible, because 
> the protocols as defined and implemented weren't really composed of discrete 
> features. The evolution of loss-based congestion control, for instance, was 
>

Re: [Taps] TCP components

[Michael Welzl]

> On 18 Jun 2015, at 10:48, Mirja Kühlewind  
> wrote:
> 
> Hi Joe,
> 
> I believe the approach Michael is proposing is to look at existing APIs as a 
> starting point; not only abstract APIs.

No, wrong. Only abstract ones from RFCs, I said this before. These things would 
typically have preceding IETF debate, whereas trying to cover implementations 
is a huge and probably meaningless endeavour (the bar may be high for adding 
function calls to an API on system X and low for an API on system Y).


> The assumption is that someone who implemented/designed an API, thought that 
> it would be worth to provide a configuration possibility to the higher layer. 
> This assumption is more true for SCTP than for TCP because there are quite a 
> few different TCP implementation that are grown over time. Quite often a new 
> interface was only created because a new feature was added to TCP; and to be 
> on the safe side we allow the user to turn it off again.
> 
> That’s the reason why I prefer the approach we are/I'm taking right now 
> (analyzing components). I think we should still describe the abstract API of 
> RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but I 
> personally would not and will not spend too much time analyzing other API. 
> However, everybody who has time and is interested in this can of course 
> provide his/her outcome as input for this document and we will happily take 
> it and compare it to what we have so far.

But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), not 
implementations out there.

More below, answering Joe  (hm, that rhymes ;-)  ) -


> 
> Mirja
> 
> 
>> Am 17.06.2015 um 20:10 schrieb Joe Touch :
>> 
>> 
>> 
>> On 6/17/2015 1:44 AM, Michael Welzl wrote:
>>> I think that this discussion with Joe maybe suffered from focusing on
>>> TCP. 
>> 
>> To be fair, TCP has a simpler abstract API.
>> 
>>> SCTP is perhaps a better starting point because it supports
>>> almost everything. 
>> 
>> IMO, that makes it very hard as a starting point, and I also think that
>> TCP's variant of an API description is much better as an example.
>> 
>> E.g., Section 10 of RFC4960 claims it defines an abstract API
>> (ULP-to_SCTP), but it begins by describing a call to initialize a data
>> structure (INITIALIZE). That's decidedly NOT an abstract API; it's a
>> generic description of an implementation issue.
>> 
>> IMO, if we don't understand the difference between the API in RFC793 vs.
>> that in RFC4960 (and why 793 is a better example), then this is going to
>> be a very bumpy road.

How abstract it is in the RFC indeed isn't my main concern here: it's to start 
with the interface (however abstract it is) offered to applications as 
described in the RFCs, as this reflects what the designers (with some level of 
IETF consensus) thought should be exposed.
Now, of course SCTP has more options and is more complex in its usage than TCP, 
but it covers a larger part of the space of services in protocols - so I 
thought it's a good starting point, as in: 80% done by looking at 1 protocol, 
check the others for the remaining 20%. Something like that.

This is just me being pragmatic and trying to have a more systematic approach 
to developing a list of services. I agree with Brian that some level of 
arbitrariness will always be there, but we must try to minimize it I think.

Cheers,
Michael

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

Re: [Taps] TCP components

[Mirja Kühlewind]

Hi Joe,

I believe the approach Michael is proposing is to look at existing APIs as a 
starting point; not only abstract APIs. The assumption is that someone who 
implemented/designed an API, thought that it would be worth to provide a 
configuration possibility to the higher layer. This assumption is more true for 
SCTP than for TCP because there are quite a few different TCP implementation 
that are grown over time. Quite often a new interface was only created because 
a new feature was added to TCP; and to be on the safe side we allow the user to 
turn it off again.

That’s the reason why I prefer the approach we are/I'm taking right now 
(analyzing components). I think we should still describe the abstract API of 
RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but I 
personally would not and will not spend too much time analyzing other API. 
However, everybody who has time and is interested in this can of course provide 
his/her outcome as input for this document and we will happily take it and 
compare it to what we have so far.

Mirja


> Am 17.06.2015 um 20:10 schrieb Joe Touch :
> 
> 
> 
> On 6/17/2015 1:44 AM, Michael Welzl wrote:
>> I think that this discussion with Joe maybe suffered from focusing on
>> TCP. 
> 
> To be fair, TCP has a simpler abstract API.
> 
>> SCTP is perhaps a better starting point because it supports
>> almost everything. 
> 
> IMO, that makes it very hard as a starting point, and I also think that
> TCP's variant of an API description is much better as an example.
> 
> E.g., Section 10 of RFC4960 claims it defines an abstract API
> (ULP-to_SCTP), but it begins by describing a call to initialize a data
> structure (INITIALIZE). That's decidedly NOT an abstract API; it's a
> generic description of an implementation issue.
> 
> IMO, if we don't understand the difference between the API in RFC793 vs.
> that in RFC4960 (and why 793 is a better example), then this is going to
> be a very bumpy road.
> 
> 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] TCP components

[Aaron Falk]

Some suggested homework for the group: if you haven't done so recently,
read section 3.8 of RFC793.  (It's only 8 pages.)

--aaron


On Wed, Jun 17, 2015 at 2:10 PM, Joe Touch  wrote:

>
> IMO, if we don't understand the difference between the API in RFC793 vs.
> that in RFC4960 (and why 793 is a better example), then this is going to
> be a very bumpy road.
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] TCP components

[Joe Touch]

On 6/17/2015 1:44 AM, Michael Welzl wrote:
> I think that this discussion with Joe maybe suffered from focusing on
> TCP. 

To be fair, TCP has a simpler abstract API.

> SCTP is perhaps a better starting point because it supports
> almost everything. 

IMO, that makes it very hard as a starting point, and I also think that
TCP's variant of an API description is much better as an example.

E.g., Section 10 of RFC4960 claims it defines an abstract API
(ULP-to_SCTP), but it begins by describing a call to initialize a data
structure (INITIALIZE). That's decidedly NOT an abstract API; it's a
generic description of an implementation issue.

IMO, if we don't understand the difference between the API in RFC793 vs.
that in RFC4960 (and why 793 is a better example), then this is going to
be a very bumpy road.

Joe

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

Re: [Taps] TCP components

[Erik Nygren]

Another major item to add to the list would be:

- MTU/MSS negotiation and management, including initial negotiation,
response to packet-too-big signals from middle-boxes, and optional probing.

To what degree is it worth talking about known design limitations and
issues associated with each?  For example, checksums in TCP not being large
enough to detect errors in many high-volume real-world scenarios?
Erik


On Jun 11, 2015 7:53 AM, "Mirja Kühlewind" 
wrote:

> Hi all,
>
> we gave it a first try to rewrite the component section for TCP. The
> insight I took from the discussion on the list is that components probably
> are much more linked to the implementation (choices) a certain protocol
> made while features are probably more high-level having the question in
> mind what does an application potentially want/need to know.
>
> So for the components in TCP we now have the following list:
>
> - Connection-oriented bidirectional communication using three-way
> handshake connection setup with
> feature negotiation and an explicit distinction between passive
> and active open:
> This implies both unicast addressing and a guarantee of return
> routability.
> - Single stream-oriented transmission:
> The stream abstraction atop the datagram service provided by IP is
> implemented by dividing
> the stream into segments.
> - Limited control over segment transmission scheduling (Nagle's algorithm):
> This allows for delay minimization in interactive applications.
> - Port multiplexing, with application-to-port mapping during connection
> setup:
> Note that in the presence of network address and port translation
> (NAPT), TCP ports are
> in effect part of the endpoint address for forwarding purposes.
> - Full reliability based on ack-based loss detection and retransmission:
> Loss is sensed using duplicated acks ("fast retransmit"), which
> places a lower bound on
> the delay inherent in this approach to reliability.
> - Error detection based on a checksum covering the network and transport
> headers as well as payload:
> Packets that are detected as corrupted are dropped, relying on the
> reliability mechanism
> to retransmit them.
> - Window-based flow control, with receiver-side window management and
> signaling of available window:
> Scaling the flow control window beyond 64kB requires the use of an
> optional feature,
> which has performance implications in environments where this
> option is not supported.
> - Window-based congestion control reacting to loss, delay, retransmission
> timeout, or
> an explicit congestion signal (ECN):
> Most commonly used is a loss signal from the reliability
> component's retransmission mechanism.
> TCP reacts to a congestion signal by reducing the size of the
> congestion window;
> retransmission timeout is generally handled with a larger reaction
> than other signals.
>
> We are currently still working on the list of features that results from
> thiese components but we are not there yet. Probably we not only need the
> features itself but also properties/aspects (or however you want to call
> this) of the feature. We already had this discussion a bit but wanted to
> postpone the decision if we really need to define an own term for this
> until we are sure that we need it.
>
> We are posting this list of (TCP) components now because we would like to
> get some feedback if this goes into the right direction/is on the right
> level of detail before we go on and apply this also to other protocols.
>
> Brian and Mirja
>
>
>
> ___
> 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] TCP components

[Brian Trammell]

hi Michael, all,

A couple of random points inline at various levels of quotation...

> On 17 Jun 2015, at 10:44, Michael Welzl  wrote:
> 
> 
> On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind 
>  wrote:
> 
>> Hi Michael,
>> 
>> see below.
>> 
>>> Am 17.06.2015 um 09:36 schrieb Michael Welzl :
>>> 
>>> Hi,
>>> 
>>> 
 On 11 Jun 2015, at 13:52, Mirja Kühlewind 
  wrote:
 
 Hi all,
 
 we gave it a first try to rewrite the component section for TCP. The 
 insight I took from the discussion on the list is that components probably 
 are much more linked to the implementation (choices) a certain protocol 
 made while features are probably more high-level having the question in 
 mind what does an application potentially want/need to know.
 
 So for the components in TCP we now have the following list:
 
 - Connection-oriented bidirectional communication using three-way 
 handshake connection setup with
feature negotiation and an explicit distinction between passive and 
 active open:
This implies both unicast addressing and a guarantee of return 
 routability.
 - Single stream-oriented transmission:
The stream abstraction atop the datagram service provided by IP is 
 implemented by dividing
the stream into segments.
 - Limited control over segment transmission scheduling (Nagle's algorithm):
This allows for delay minimization in interactive applications.
 - Port multiplexing, with application-to-port mapping during connection 
 setup:
Note that in the presence of network address and port translation 
 (NAPT), TCP ports are
in effect part of the endpoint address for forwarding purposes.
 - Full reliability based on ack-based loss detection and retransmission:
Loss is sensed using duplicated acks ("fast retransmit"), which places 
 a lower bound on
the delay inherent in this approach to reliability.
 - Error detection based on a checksum covering the network and transport 
 headers as well as payload:
Packets that are detected as corrupted are dropped, relying on the 
 reliability mechanism
to retransmit them.
 - Window-based flow control, with receiver-side window management and 
 signaling of available window:
Scaling the flow control window beyond 64kB requires the use of an 
 optional feature,
which has performance implications in environments where this option is 
 not supported.
 - Window-based congestion control reacting to loss, delay, retransmission 
 timeout, or
an explicit congestion signal (ECN):
Most commonly used is a loss signal from the reliability component's 
 retransmission mechanism.
TCP reacts to a congestion signal by reducing the size of the 
 congestion window;
retransmission timeout is generally handled with a larger reaction than 
 other signals.
 
 We are currently still working on the list of features that results from 
 thiese components but we are not there yet. Probably we not only need the 
 features itself but also properties/aspects (or however you want to call 
 this) of the feature. We already had this discussion a bit but wanted to 
 postpone the decision if we really need to define an own term for this 
 until we are sure that we need it.
 
 We are posting this list of (TCP) components now because we would like to 
 get some feedback if this goes into the right direction/is on the right 
 level of detail before we go on and apply this also to other protocols.
>>> 
>>> I agree that the list below is closer to what I think a "component" should 
>>> be ... but looking at it, is it not even clearer now that components are 
>>> not what TAPS is after? To me this list now contains lots and lots of 
>>> details that are irrelevant to the service provided to the application.

That's part of the point we're trying to address here. The realization we had 
here is that components *don't* necessarily map to feature, and it's not clear 
that we can simply ignore those components that don't map, since they may have 
impact on the interfaces/features it is possible to (reasonably) implement atop 
those protocols.

>>> Not harmful to list but pretty useless?!

Let's start with TCP as probably the most difficult example (indeed, that's why 
we worked out this "new" arrangement of components for TCP first). A completely 
clean and unambiguous decomposition of TCP into its features -- what, I agree, 
we're after in the end -- is not *really* possible, because the protocols as 
defined and implemented weren't really composed of discrete features. The 
evolution of loss-based congestion control, for instance, was predicated on the 
particular loss signals that were available at the time it was first defined. 
The error detection mechanism likewise relies on the fact that reliabil

Re: [Taps] TCP components

[Michael Welzl]

On Jun 17, 2015, at 10:28 AM, Mirja Kühlewind  
wrote:

> Hi Michael,
> 
> see below.
> 
>> Am 17.06.2015 um 09:36 schrieb Michael Welzl :
>> 
>> Hi,
>> 
>> 
>>> On 11 Jun 2015, at 13:52, Mirja Kühlewind  
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> we gave it a first try to rewrite the component section for TCP. The 
>>> insight I took from the discussion on the list is that components probably 
>>> are much more linked to the implementation (choices) a certain protocol 
>>> made while features are probably more high-level having the question in 
>>> mind what does an application potentially want/need to know.
>>> 
>>> So for the components in TCP we now have the following list:
>>> 
>>> - Connection-oriented bidirectional communication using three-way handshake 
>>> connection setup with
>>> feature negotiation and an explicit distinction between passive and 
>>> active open:
>>> This implies both unicast addressing and a guarantee of return 
>>> routability.
>>> - Single stream-oriented transmission:
>>> The stream abstraction atop the datagram service provided by IP is 
>>> implemented by dividing
>>> the stream into segments.
>>> - Limited control over segment transmission scheduling (Nagle's algorithm):
>>> This allows for delay minimization in interactive applications.
>>> - Port multiplexing, with application-to-port mapping during connection 
>>> setup:
>>> Note that in the presence of network address and port translation 
>>> (NAPT), TCP ports are
>>> in effect part of the endpoint address for forwarding purposes.
>>> - Full reliability based on ack-based loss detection and retransmission:
>>> Loss is sensed using duplicated acks ("fast retransmit"), which places 
>>> a lower bound on
>>> the delay inherent in this approach to reliability.
>>> - Error detection based on a checksum covering the network and transport 
>>> headers as well as payload:
>>> Packets that are detected as corrupted are dropped, relying on the 
>>> reliability mechanism
>>> to retransmit them.
>>> - Window-based flow control, with receiver-side window management and 
>>> signaling of available window:
>>> Scaling the flow control window beyond 64kB requires the use of an 
>>> optional feature,
>>> which has performance implications in environments where this option is 
>>> not supported.
>>> - Window-based congestion control reacting to loss, delay, retransmission 
>>> timeout, or
>>> an explicit congestion signal (ECN):
>>> Most commonly used is a loss signal from the reliability component's 
>>> retransmission mechanism.
>>> TCP reacts to a congestion signal by reducing the size of the 
>>> congestion window;
>>> retransmission timeout is generally handled with a larger reaction than 
>>> other signals.
>>> 
>>> We are currently still working on the list of features that results from 
>>> thiese components but we are not there yet. Probably we not only need the 
>>> features itself but also properties/aspects (or however you want to call 
>>> this) of the feature. We already had this discussion a bit but wanted to 
>>> postpone the decision if we really need to define an own term for this 
>>> until we are sure that we need it.
>>> 
>>> We are posting this list of (TCP) components now because we would like to 
>>> get some feedback if this goes into the right direction/is on the right 
>>> level of detail before we go on and apply this also to other protocols.
>> 
>> I agree that the list below is closer to what I think a "component" should 
>> be ... but looking at it, is it not even clearer now that components are not 
>> what TAPS is after? To me this list now contains lots and lots of details 
>> that are irrelevant to the service provided to the application. Not harmful 
>> to list but pretty useless?!
> 
> In this case we decided to list/discuss rather some more details, so that 
> people can understand what we had in mind. We might remove some of these 
> details/explanations at the end (or move those parts that are actually 
> relevant into the feature section (4)).
> 
>> 
>> And how do you draw the line for what goes in and out of such a list? E.g., 
>> on which basis did you decide that FACK, FRTO, PRR and DSACK are not 
>> mentioned?
> 
> We tried to ask ourself which parts have an effect on the behavior of the 
> flow that could potentially be of interest for the application. We might have 
> missed some points. Actually Gorry already point out some.

Okay; btw just to be clear, I didn't mean that FACK etc. should be in the list 
- on the contrary! My point was really about "how do you draw the line", which 
you answered in the first sentence here.


> The next step is to work on the feature list and figure out how these things 
> that are interesting for the application would be described in a more general 
> way (independent of the concrete algorithm that is used by one protocol) and 
> also discuss which features actually should be exposed becau

Re: [Taps] TCP components

[Mirja Kühlewind]

Hi Michael,

see below.

> Am 17.06.2015 um 09:36 schrieb Michael Welzl :
> 
> Hi,
> 
> 
>> On 11 Jun 2015, at 13:52, Mirja Kühlewind  
>> wrote:
>> 
>> Hi all,
>> 
>> we gave it a first try to rewrite the component section for TCP. The insight 
>> I took from the discussion on the list is that components probably are much 
>> more linked to the implementation (choices) a certain protocol made while 
>> features are probably more high-level having the question in mind what does 
>> an application potentially want/need to know.
>> 
>> So for the components in TCP we now have the following list:
>> 
>> - Connection-oriented bidirectional communication using three-way handshake 
>> connection setup with
>>  feature negotiation and an explicit distinction between passive and 
>> active open:
>>  This implies both unicast addressing and a guarantee of return 
>> routability.
>> - Single stream-oriented transmission:
>>  The stream abstraction atop the datagram service provided by IP is 
>> implemented by dividing
>>  the stream into segments.
>> - Limited control over segment transmission scheduling (Nagle's algorithm):
>>  This allows for delay minimization in interactive applications.
>> - Port multiplexing, with application-to-port mapping during connection 
>> setup:
>>  Note that in the presence of network address and port translation 
>> (NAPT), TCP ports are
>>  in effect part of the endpoint address for forwarding purposes.
>> - Full reliability based on ack-based loss detection and retransmission:
>>  Loss is sensed using duplicated acks ("fast retransmit"), which places 
>> a lower bound on
>>  the delay inherent in this approach to reliability.
>> - Error detection based on a checksum covering the network and transport 
>> headers as well as payload:
>>  Packets that are detected as corrupted are dropped, relying on the 
>> reliability mechanism
>>  to retransmit them.
>> - Window-based flow control, with receiver-side window management and 
>> signaling of available window:
>>  Scaling the flow control window beyond 64kB requires the use of an 
>> optional feature,
>>  which has performance implications in environments where this option is 
>> not supported.
>> - Window-based congestion control reacting to loss, delay, retransmission 
>> timeout, or
>>  an explicit congestion signal (ECN):
>>  Most commonly used is a loss signal from the reliability component's 
>> retransmission mechanism.
>>  TCP reacts to a congestion signal by reducing the size of the 
>> congestion window;
>>  retransmission timeout is generally handled with a larger reaction than 
>> other signals.
>> 
>> We are currently still working on the list of features that results from 
>> thiese components but we are not there yet. Probably we not only need the 
>> features itself but also properties/aspects (or however you want to call 
>> this) of the feature. We already had this discussion a bit but wanted to 
>> postpone the decision if we really need to define an own term for this until 
>> we are sure that we need it.
>> 
>> We are posting this list of (TCP) components now because we would like to 
>> get some feedback if this goes into the right direction/is on the right 
>> level of detail before we go on and apply this also to other protocols.
> 
> I agree that the list below is closer to what I think a "component" should be 
> ... but looking at it, is it not even clearer now that components are not 
> what TAPS is after? To me this list now contains lots and lots of details 
> that are irrelevant to the service provided to the application. Not harmful 
> to list but pretty useless?!

In this case we decided to list/discuss rather some more details, so that 
people can understand what we had in mind. We might remove some of these 
details/explanations at the end (or move those parts that are actually relevant 
into the feature section (4)).

> 
> And how do you draw the line for what goes in and out of such a list? E.g., 
> on which basis did you decide that FACK, FRTO, PRR and DSACK are not 
> mentioned?

We tried to ask ourself which parts have an effect on the behavior of the flow 
that could potentially be of interest for the application. We might have missed 
some points. Actually Gorry already point out some.

The next step is to work on the feature list and figure out how these things 
that are interesting for the application would be described in a more general 
way (independent of the concrete algorithm that is used by one protocol) and 
also discuss which features actually should be exposed because they have a real 
use for the application.

> 
> To me, this whole thing is just too full of arbitrariness. We should aim for 
> a systematic approach that minimizes the number of arbitrary decisions made 
> IMO.

For us the systematic approach is to look at the implementation of existing 
protocol an figure out which algorithm have an influence on the t

Re: [Taps] TCP components

[Michael Welzl]

Hi,


> On 11 Jun 2015, at 13:52, Mirja Kühlewind  
> wrote:
> 
> Hi all,
> 
> we gave it a first try to rewrite the component section for TCP. The insight 
> I took from the discussion on the list is that components probably are much 
> more linked to the implementation (choices) a certain protocol made while 
> features are probably more high-level having the question in mind what does 
> an application potentially want/need to know.
> 
> So for the components in TCP we now have the following list:
> 
> - Connection-oriented bidirectional communication using three-way handshake 
> connection setup with
>   feature negotiation and an explicit distinction between passive and 
> active open:
>   This implies both unicast addressing and a guarantee of return 
> routability.
> - Single stream-oriented transmission:
>   The stream abstraction atop the datagram service provided by IP is 
> implemented by dividing
>   the stream into segments.
> - Limited control over segment transmission scheduling (Nagle's algorithm):
>   This allows for delay minimization in interactive applications.
> - Port multiplexing, with application-to-port mapping during connection setup:
>   Note that in the presence of network address and port translation 
> (NAPT), TCP ports are
>   in effect part of the endpoint address for forwarding purposes.
> - Full reliability based on ack-based loss detection and retransmission:
>   Loss is sensed using duplicated acks ("fast retransmit"), which places 
> a lower bound on
>   the delay inherent in this approach to reliability.
> - Error detection based on a checksum covering the network and transport 
> headers as well as payload:
>   Packets that are detected as corrupted are dropped, relying on the 
> reliability mechanism
>   to retransmit them.
> - Window-based flow control, with receiver-side window management and 
> signaling of available window:
>   Scaling the flow control window beyond 64kB requires the use of an 
> optional feature,
>   which has performance implications in environments where this option is 
> not supported.
> - Window-based congestion control reacting to loss, delay, retransmission 
> timeout, or
>   an explicit congestion signal (ECN):
>   Most commonly used is a loss signal from the reliability component's 
> retransmission mechanism.
>   TCP reacts to a congestion signal by reducing the size of the 
> congestion window;
>   retransmission timeout is generally handled with a larger reaction than 
> other signals.
> 
> We are currently still working on the list of features that results from 
> thiese components but we are not there yet. Probably we not only need the 
> features itself but also properties/aspects (or however you want to call 
> this) of the feature. We already had this discussion a bit but wanted to 
> postpone the decision if we really need to define an own term for this until 
> we are sure that we need it.
> 
> We are posting this list of (TCP) components now because we would like to get 
> some feedback if this goes into the right direction/is on the right level of 
> detail before we go on and apply this also to other protocols.

I agree that the list below is closer to what I think a "component" should be 
... but looking at it, is it not even clearer now that components are not what 
TAPS is after? To me this list now contains lots and lots of details that are 
irrelevant to the service provided to the application. Not harmful to list but 
pretty useless?!

And how do you draw the line for what goes in and out of such a list? E.g., on 
which basis did you decide that FACK, FRTO, PRR and DSACK are not mentioned?

To me, this whole thing is just too full of arbitrariness. We should aim for a 
systematic approach that minimizes the number of arbitrary decisions made IMO.

Cheers,
Michael

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

Re: [Taps] TCP components

[Joe Touch]

On 6/11/2015 5:30 AM, go...@erg.abdn.ac.uk wrote:
...
>> - Port multiplexing, with application-to-port mapping during connection
>> setup:
> 
> GF: Thinking on this, is application-to-port mapping really a TCP
> function? port-mapping is similar in other transports, and doesn't really
> have any different support in TCP (contrast to the Service Code in DCCP)

The assumption of app-to-port mapping is part of how assigned ports are,
well, assigned.

>>  Note that in the presence of network address and port translation 
>> (NAPT),
>> TCP
>> ports are
>>  in effect part of the endpoint address for forwarding purposes.
>>
> GF: This is the case only for those middle boxes that do NAPT,
> load-ballancing etc, saying they are part of the endpoint address is to me
> confusing forwarding by middle boxes from forwarding by routers - I'd
> prefer to be more careful here.

Ports are part of the connection identifier, in conjunction with the
endpoint address.

The fact that NATs or any other devices remap, translate, or overload
that function (i.e., using it for forwarding decisions) is not relevant
to TCP's view of these values or to the service TCP provides, IMO.

Joe

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

Re: [Taps] TCP components

[Mirja Kühlewind]

Hi Mohamed,

see below.



- Limited control over segment transmission scheduling (Nagle's
algorithm):
This allows for delay minimization in interactive applications.



GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce delay.



Yes, I think we wanted to say the same thing here; don't really see the 
difference...


  I don't understand this delay optimization. Is it thanks to Nagle's  algorithm
or for the possibility of its deactivation? Because it's known that this
algorithm increase delay and so became unsuitable for delay-sensitive
applications...



Yes, the delay is reduced if you deactivate it.

The component is the fact that there is an algorithm that will influence when
packets are sent (if data is available and the sending window is large enough).

Mirja



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

Re: [Taps] TCP components

[Mohamed Oulmahdi]

Hi,

On Jun 11, 2015 4:11 PM, "Mirja Kühlewind" 
wrote:
>
> Hi Gorry,
>
> see below.
>
>
>>> - Limited control over segment transmission scheduling (Nagle's
>>> algorithm):
>>> This allows for delay minimization in interactive applications.
>>
>>
>> GF: Not quite - To me, it prevents increased delay from the TCP protocol.
>> It doesn't really control anything to reduce delay.
>
>
> Yes, I think we wanted to say the same thing here; don't really see the
difference...

 I don't understand this delay optimization. Is it thanks to Nagle's
algorithm or for the possibility of its deactivation? Because it's known
that this algorithm increase delay and so became unsuitable for
delay-sensitive applications...
>
>
>>
>>> - Port multiplexing, with application-to-port mapping during connection
>>> setup:
>>
>>
>> GF: Thinking on this, is application-to-port mapping really a TCP
>> function? port-mapping is similar in other transports, and doesn't really
>> have any different support in TCP (contrast to the Service Code in DCCP)
>
>
> No it's not specific to TCP but it's still something you get when you use
TCP and that's what we wanted to document here.
>
>
>>
>>> Note that in the presence of network address and port
translation (NAPT),
>>> TCP
>>> ports are
>>> in effect part of the endpoint address for forwarding purposes.
>>>
>> GF: This is the case only for those middle boxes that do NAPT,
>> load-ballancing etc, saying they are part of the endpoint address is to
me
>> confusing forwarding by middle boxes from forwarding by routers - I'd
>> prefer to be more careful here.
>
>
> I agree that we should be careful here about the wording. However this
was only a note to explain slightly better what we had in mind here.
>
>
>>
>>> - Full reliability based on ack-based loss detection and retransmission:
>>> Loss is sensed using duplicated acks ("fast retransmit"), which
places a
>>> lower
>>> bound on
>>> the delay inherent in this approach to reliability.
>>>
>> GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in
>> SCPS-TP and probably doesn't nee dot be mentioned).
>
>
> I'd say DupACK and RTO is both ACK-based loss detection where in the
latter case no ACKs are received for a certain time. However we can add
both explicitly here. What we probably should mention is that RTO puts a
maximum bound on the delay. I agree that SACK should probably be mentioned
as well here because this again helps speeding up the retransmissions and
therefore helps reducing delay by head of line blocking.
>
>
>>
>>> - Error detection based on a checksum covering the network and transport
>>> headers
>>> as well as payload:
>>> Packets that are detected as corrupted are dropped, relying on
the
>>> reliability
>>> mechanism
>>> to retransmit them.
>>>
>> GF: True (actually packets header checks and data segments + pseudo
header)
>
>
> Sorry, what do you mean by pseudo header here?
>
>
>>
>>> - Window-based flow control, with receiver-side window management and
>>> signaling
>>> of available window:
>>> Scaling the flow control window beyond 64kB requires the use of
an
>>> optional
>>> feature,
>>> which has performance implications in environments where this
option is
>>> not
>>> supported.
>>>
>> GF: Does environment mean path? or something else?
>
>
> Both option stripping on the path or no support of the receiving end
point. Can make this more clear.
>
>
>
>>
>>> - Window-based congestion control reacting to loss, delay,
retransmission
>>> timeout, or
>>> an explicit congestion signal (ECN):
>>> Most commonly used is a loss signal from the reliability
component's
>>> retransmission mechanism.
>>> TCP reacts to a congestion signal by reducing the size of the
congestion
>>> window;
>>> retransmission timeout is generally handled with a larger
reaction than
>>> other  signals.
>>>
>> GF: Generally? Shouldn't RTO imply loss of path state and always result
in
>> a larger reaction? (RTO back-off for instance).
>
>
> In principle yes, but you could easily also implement an congestion
control algorithm there the window is set to minimum for every dupACK. The
'generally' is because there is not the one and only congestion control in
TCP and therefore you never know what people actually implement.
>
>
> Mirja
>
>
> ___
> 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] TCP components

[gorry]

We seem to agree mostly, a few small comments in-line

> Hi Gorry,
>
> see below.
>
>>> - Limited control over segment transmission scheduling (Nagle's
>>> algorithm):
>>> This allows for delay minimization in interactive applications.
>>
>> GF: Not quite - To me, it prevents increased delay from the TCP
>> protocol.
>> It doesn't really control anything to reduce delay.
>
> Yes, I think we wanted to say the same thing here; don't really see the
> difference...
>
>>
>>> - Port multiplexing, with application-to-port mapping during connection
>>> setup:
>>
>> GF: Thinking on this, is application-to-port mapping really a TCP
>> function? port-mapping is similar in other transports, and doesn't
>> really
>> have any different support in TCP (contrast to the Service Code in DCCP)
>
> No it's not specific to TCP but it's still something you get when you use
> TCP and that's what we wanted to document here.
>
So would we have the same text in UDP, SCTP, etc?
>>
>>> Note that in the presence of network address and port translation
>>> (NAPT),
>>> TCP
>>> ports are
>>> in effect part of the endpoint address for forwarding purposes.
>>>
>> GF: This is the case only for those middle boxes that do NAPT,
>> load-ballancing etc, saying they are part of the endpoint address is to
>> me
>> confusing forwarding by middle boxes from forwarding by routers - I'd
>> prefer to be more careful here.
>
> I agree that we should be careful here about the wording. However this was
> only a note to explain slightly better what we had in mind here.
>
>>
>>> - Full reliability based on ack-based loss detection and
>>> retransmission:
>>> Loss is sensed using duplicated acks ("fast retransmit"), which places
>>> a lower bound on
>>> the delay inherent in this approach to reliability.
>>>
>> GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in
>> SCPS-TP and probably doesn't nee dot be mentioned).
>
> I'd say DupACK and RTO is both ACK-based loss detection where in the
> latter case
> no ACKs are received for a certain time. However we can add both
> explicitly
> here. What we probably should mention is that RTO puts a maximum bound on
> the
> delay. I agree that SACK should probably be mentioned as well here because
> this
> again helps speeding up the retransmissions and therefore helps reducing
> delay
> by head of line blocking.
>
>>
>>> - Error detection based on a checksum covering the network and
>>> transport
>>> headers
>>> as well as payload:
>>> Packets that are detected as corrupted are dropped, relying on the
>>> reliability
>>> mechanism
>>> to retransmit them.
>>>
>> GF: True (actually packets header checks and data segments + pseudo
>> header)
>
> Sorry, what do you mean by pseudo header here?
>
Only that TCP combines the segment data with the pseudo header from IP to
perform the checksum. For IPv4, this also assumes that each IP datagram
also passes the IP datagram checksum for each datagram (fragment)

>>
>>> - Window-based flow control, with receiver-side window management and
>>> signaling
>>> of available window:
>>> Scaling the flow control window beyond 64kB requires the use of an
>>> optional
>>> feature,
>>> which has performance implications in environments where this option
>>> is
>>> not
>>> supported.
>>>
>> GF: Does environment mean path? or something else?
>
> Both option stripping on the path or no support of the receiving end
> point. Can make this more clear.
>
I'd prefer to be clear on this.
>
>>
>>> - Window-based congestion control reacting to loss, delay,
>>> retransmission
>>> timeout, or
>>> an explicit congestion signal (ECN):
>>> Most commonly used is a loss signal from the reliability component's
>>> retransmission mechanism.
>>> TCP reacts to a congestion signal by reducing the size of the
>>> congestion
>>> window;
>>> retransmission timeout is generally handled with a larger reaction
>>> than
>>> other  signals.
>>>
>> GF: Generally? Shouldn't RTO imply loss of path state and always result
>> in
>> a larger reaction? (RTO back-off for instance).
>
> In principle yes, but you could easily also implement an congestion
> control
> algorithm there the window is set to minimum for every dupACK. The
> 'generally'
> is because there is not the one and only congestion control in TCP and
> therefore
> you never know what people actually implement.
>
> Mirja
>
>
Gorry

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

Re: [Taps] TCP components

[Mirja Kühlewind]

Hi Gorry,

see below.


- Limited control over segment transmission scheduling (Nagle's
algorithm):
This allows for delay minimization in interactive applications.


GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce delay.


Yes, I think we wanted to say the same thing here; don't really see the 
difference...





- Port multiplexing, with application-to-port mapping during connection
setup:


GF: Thinking on this, is application-to-port mapping really a TCP
function? port-mapping is similar in other transports, and doesn't really
have any different support in TCP (contrast to the Service Code in DCCP)


No it's not specific to TCP but it's still something you get when you use TCP 
and that's what we wanted to document here.





Note that in the presence of network address and port translation 
(NAPT),
TCP
ports are
in effect part of the endpoint address for forwarding purposes.


GF: This is the case only for those middle boxes that do NAPT,
load-ballancing etc, saying they are part of the endpoint address is to me
confusing forwarding by middle boxes from forwarding by routers - I'd
prefer to be more careful here.


I agree that we should be careful here about the wording. However this was only 
a note to explain slightly better what we had in mind here.





- Full reliability based on ack-based loss detection and retransmission:
Loss is sensed using duplicated acks ("fast retransmit"), which places a
lower
bound on
the delay inherent in this approach to reliability.


GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in
SCPS-TP and probably doesn't nee dot be mentioned).


I'd say DupACK and RTO is both ACK-based loss detection where in the latter case 
no ACKs are received for a certain time. However we can add both explicitly 
here. What we probably should mention is that RTO puts a maximum bound on the 
delay. I agree that SACK should probably be mentioned as well here because this 
again helps speeding up the retransmissions and therefore helps reducing delay 
by head of line blocking.





- Error detection based on a checksum covering the network and transport
headers
as well as payload:
Packets that are detected as corrupted are dropped, relying on the
reliability
mechanism
to retransmit them.


GF: True (actually packets header checks and data segments + pseudo header)


Sorry, what do you mean by pseudo header here?




- Window-based flow control, with receiver-side window management and
signaling
of available window:
Scaling the flow control window beyond 64kB requires the use of an
optional
feature,
which has performance implications in environments where this option is
not
supported.


GF: Does environment mean path? or something else?


Both option stripping on the path or no support of the receiving end point. Can 
make this more clear.






- Window-based congestion control reacting to loss, delay, retransmission
timeout, or
an explicit congestion signal (ECN):
Most commonly used is a loss signal from the reliability component's
retransmission mechanism.
TCP reacts to a congestion signal by reducing the size of the congestion
window;
retransmission timeout is generally handled with a larger reaction than
other  signals.


GF: Generally? Shouldn't RTO imply loss of path state and always result in
a larger reaction? (RTO back-off for instance).


In principle yes, but you could easily also implement an congestion control 
algorithm there the window is set to minimum for every dupACK. The 'generally' 
is because there is not the one and only congestion control in TCP and therefore 
you never know what people actually implement.


Mirja


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

Re: [Taps] TCP components

[gorry]

I have a few comments, see below:

> Hi all,
>
> we gave it a first try to rewrite the component section for TCP. The
> insight I
> took from the discussion on the list is that components probably are much
> more
> linked to the implementation (choices) a certain protocol made while
> features
> are probably more high-level having the question in mind what does an
> application potentially want/need to know.
>
> So for the components in TCP we now have the following list:
>
> - Connection-oriented bidirectional communication using three-way
> handshake
> connection setup with
>   feature negotiation and an explicit distinction between passive and
> active open:
>   This implies both unicast addressing and a guarantee of return
> routability.
> - Single stream-oriented transmission:
>   The stream abstraction atop the datagram service provided by IP is
> implemented
> by dividing
>   the stream into segments.
> - Limited control over segment transmission scheduling (Nagle's
> algorithm):
>   This allows for delay minimization in interactive applications.

GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce delay.

> - Port multiplexing, with application-to-port mapping during connection
> setup:

GF: Thinking on this, is application-to-port mapping really a TCP
function? port-mapping is similar in other transports, and doesn't really
have any different support in TCP (contrast to the Service Code in DCCP)

>   Note that in the presence of network address and port translation 
> (NAPT),
> TCP
> ports are
>   in effect part of the endpoint address for forwarding purposes.
>
GF: This is the case only for those middle boxes that do NAPT,
load-ballancing etc, saying they are part of the endpoint address is to me
confusing forwarding by middle boxes from forwarding by routers - I'd
prefer to be more careful here.

> - Full reliability based on ack-based loss detection and retransmission:
>   Loss is sensed using duplicated acks ("fast retransmit"), which places a
> lower
> bound on
>   the delay inherent in this approach to reliability.
>
GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in
SCPS-TP and probably doesn't nee dot be mentioned).

> - Error detection based on a checksum covering the network and transport
> headers
> as well as payload:
>   Packets that are detected as corrupted are dropped, relying on the
> reliability
> mechanism
>   to retransmit them.
>
GF: True (actually packets header checks and data segments + pseudo header)

> - Window-based flow control, with receiver-side window management and
> signaling
> of available window:
>   Scaling the flow control window beyond 64kB requires the use of an
> optional
> feature,
>   which has performance implications in environments where this option is
> not
> supported.
>
GF: Does environment mean path? or something else?

> - Window-based congestion control reacting to loss, delay, retransmission
> timeout, or
>   an explicit congestion signal (ECN):
>   Most commonly used is a loss signal from the reliability component's
> retransmission mechanism.
>   TCP reacts to a congestion signal by reducing the size of the congestion
> window;
>   retransmission timeout is generally handled with a larger reaction than
> other  signals.
>
GF: Generally? Shouldn't RTO imply loss of path state and always result in
a larger reaction? (RTO back-off for instance).

>
> We are currently still working on the list of features that results from
> thiese
> components but we are not there yet. Probably we not only need the
> features
> itself but also properties/aspects (or however you want to call this) of
> the
> feature. We already had this discussion a bit but wanted to postpone the
> decision if we really need to define an own term for this until we are
> sure that
> we need it.
>
> We are posting this list of (TCP) components now because we would like to
> get
> some feedback if this goes into the right direction/is on the right level
> of
> detail before we go on and apply this also to other protocols.
>
> Brian and Mirja
>
>
>
> ___
> 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