Re: [Taps] TCP components

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 PU

Re: [Taps] TCP components

t;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 n

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

Re: [Taps] TCP components

> 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 ar

Re: [Taps] TCP components

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 implement

Re: [Taps] TCP components

sday, 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 >> start

Re: [Taps] TCP components

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 >Subje

Re: [Taps] TCP components

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.

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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

Re: [Taps] TCP components

> 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 ex

Re: [Taps] TCP components

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 se

Re: [Taps] TCP components

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 deve

Re: [Taps] TCP components

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 p

Re: [Taps] TCP components

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 certai

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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 :-(

Re: [Taps] TCP components

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

Re: [Taps] TCP components

> 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. Afte

Re: [Taps] TCP components

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:

Re: [Taps] TCP components

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 ap

Re: [Taps] TCP components

> 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

Re: [Taps] TCP components

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

Re: [Taps] TCP components

+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

Re: [Taps] TCP components

> 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 >>

Re: [Taps] TCP components

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 o

Re: [Taps] TCP components

> 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, >>> >>> s

Re: [Taps] TCP components

> 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 precedin

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

Re: [Taps] TCP components

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 b

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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 com

Re: [Taps] TCP components

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 protoco

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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 d

Re: [Taps] TCP components

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 increa

Re: [Taps] TCP components

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 fr

Re: [Taps] TCP components

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

Re: [Taps] TCP components

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 > ar

[Taps] TCP components

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 i