Re: [Taps] How to handle Protocol stacks that are not equivalent

Good point, I guess this might be true for other things as well. Take SCTP for example, you might not know if it is multistream or not until after it has already been raced and the association has been established. So for some transport properties you might have to race protocols before you can det

Re: [Taps] How to handle Protocol stacks that are not equivalent

Hi, (trimmed Cc list) On 23.07.19 16:53, Anna Brunström wrote: > > *Subject:* Re: [Taps] How to handle Protocol stacks that are not > equivalent > >   > > Yes, that's correct. My interpretation is that being in the candidate > set already requires equivalence. > >   > > Same here, seems we all agr

Re: [Taps] On Profiles for TAPS Preconnections

Hi, as we seem to have rough consensus in what we want (but may still disagree how this should be achieved), I updated PR #328 in a way that might work for all of us. I also updated PR #327 the to include #328 and point at the profiles as a the way to specify common requirements instead of requ

Re: [Taps] How to handle Protocol stacks that are not equivalent

From: Taps On Behalf Of Tommy Pauly Sent: den 23 juli 2019 19:52 To: Max Franke Cc: Joe Touch ; Tommy Pauly ; Theresa Enghardt ; taps@ietf.org Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent Yes, that's correct. My interpretation is that being in the candidate set

Re: [Taps] On Profiles for TAPS Preconnections

From: Taps On Behalf Of Michael Welzl Sent: den 23 juli 2019 16:17 To: Max Franke Cc: Philipp S. Tiesel ; Tommy Pauly ; taps@ietf.org Subject: Re: [Taps] On Profiles for TAPS Preconnections On Jul 23, 2019, at 9:51 AM, Max Franke mailto:mfra...@inet.tu-berlin.de>> wrote: The API prescr

Re: [Taps] On Profiles for TAPS Preconnections

Hi all, inline > -Original Message- > From: Taps On Behalf Of Gorry Fairhurst > Sent: den 23 juli 2019 20:40 > To: Brian Trammell (IETF) > Cc: Philipp S. Tiesel ; Tommy Pauly > ; taps WG > Subject: Re: [Taps] On Profiles for TAPS Preconnections > > Hi all, see below - how near are we t

Re: [Taps] On Profiles for TAPS Preconnections

Hi all, see below - how near are we to agreement? On 23/07/2019, 14:21, Brian Trammell (IETF) wrote: hi Tommy, all, On 22 Jul 2019, at 19:15, Tommy Pauly wrote: On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel wrote: Hi, On 22. Jul 2019, at 15:09, Tommy Pauly wrote: An issue we discu

Re: [Taps] On Profiles for TAPS Preconnections

hi Tommy, all, > On 22 Jul 2019, at 19:15, Tommy Pauly > wrote: > > > >> On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel wrote: >> >> Hi, >> >>> On 22. Jul 2019, at 15:09, Tommy Pauly >>> wrote: >>> >>> An issue we discussed today in the TAPS meeting was whether or not we >>> should add

Re: [Taps] How to handle Protocol stacks that are not equivalent

Yes, that's correct. My interpretation is that being in the candidate set already requires equivalence. We can make the text more clear here, but it isn't a technical change. Thanks, Tommy > On Jul 23, 2019, at 12:05 PM, Max Franke wrote: > > So if I understand this correctly, this boils down

Re: [Taps] How to handle Protocol stacks that are not equivalent

You've specified this as if it were an individual property. You need to deal with sets of properties, perhaps including choices (A and B) or (A and C) but not (A and B and D)... This is widely known as "constraint satisfaction", unsurprisingly. Joe On 7/23/2019 8:59 AM, Tommy Pauly wrote: > Hi J

Re: [Taps] How to handle Protocol stacks that are not equivalent

So if I understand this correctly, this boils down to the fact that if two protocols are in the candidate set for racing they are also equivalent? Thus we dont have to worry about unequivalent protocols as they are never part of the same candidate set anyway?BestMaxAm 23.07.2019 11:59 schrieb Tommy

Re: [Taps] How to handle Protocol stacks that are not equivalent

Hi Joe, Yes, I completely agree. The current text in -arch expresses this as: 2. Both stacks MUST offer the same transport services, as required by the application. For example, if an application specifies that it requires reliable transmission of data, then a Protocol S

Re: [Taps] How to handle Protocol stacks that are not equivalent

> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt > wrote: > > Another important difference between TCP and UDP are Message Boundaries. > So in some cases, TCP + Framer may be equivalent to UDP. FWIW, they might provide *similar* capabilities, even only those that the app is concerned about, b

Re: [Taps] How to handle Protocol stacks that are not equivalent

> On Jul 23, 2019, at 11:19 AM, Theresa Enghardt > wrote: > > Hi, > >> On 23/07/2019, 10:31, Tommy Pauly wrote: >>> […] if you don't require reliability, then a UDP protocol stack is >>> equivalent to a message protocol over TCP. If you do require >>> reliability, then those aren't equivalent

Re: [Taps] How to handle Protocol stacks that are not equivalent

Hi, > On 23/07/2019, 10:31, Tommy Pauly wrote: >> […] if you don't require reliability, then a UDP protocol stack is >> equivalent to a message protocol over TCP. If you do require >> reliability, then those aren't equivalent. Another important difference between TCP and UDP are Message Boundarie

Re: [Taps] How to handle Protocol stacks that are not equivalent

On 23/07/2019, 10:31, Tommy Pauly wrote: My initial impression here is that any protocol stacks that provide the same transport services, and thus can be raced as candidates, need to be equivalent. It ends up being a bit tautological. The description in the architecture explains what combinati

Re: [Taps] On Profiles for TAPS Preconnections

> On 23. Jul 2019, at 10:46, Tommy Pauly > wrote: > > TransportProperties.WithProfile(profile) *is* a constructor, I believe? (Or > at least that's what I interpret and suggest). Calling it multiple times > creates two different sets of properties. It's just a convenience way, but > not the

Re: [Taps] On Profiles for TAPS Preconnections

TransportProperties.WithProfile(profile) *is* a constructor, I believe? (Or at least that's what I interpret and suggest). Calling it multiple times creates two different sets of properties. It's just a convenience way, but not the only way. Thanks, Tommy > On Jul 23, 2019, at 10:35 AM, Philip

Re: [Taps] On Profiles for TAPS Preconnections

> On 23. Jul 2019, at 09:40, Tommy Pauly wrote: > > Yes, I would be happier with suggesting something like > TransportProperties.WithProfile(profile), rather than replacing the primary > constructor. This has several drawbacks and makes things more complicated: - We need to define what shou

Re: [Taps] How to handle Protocol stacks that are not equivalent

My initial impression here is that any protocol stacks that provide the same transport services, and thus can be raced as candidates, need to be equivalent. It ends up being a bit tautological. The description in the architecture explains what combinations are allowed based on preference—if you

Re: [Taps] On Profiles for TAPS Preconnections

> On 23. Jul 2019, at 10:17, Michael Welzl wrote: > > > >> On Jul 23, 2019, at 9:51 AM, Max Franke > > wrote: >> >> >> >> The API prescribed by this document is abstract, and needs to give freedom >> to implementations to make things elegant in their part

Re: [Taps] On Profiles for TAPS Preconnections

> On Jul 23, 2019, at 9:51 AM, Max Franke wrote: > > > > The API prescribed by this document is abstract, and needs to give freedom to > implementations to make things elegant in their particular languages. > > What about having an appending, that's non-normative and not required for RFC >

Re: [Taps] On Profiles for TAPS Preconnections

The API prescribed by this document is abstract, and needs to give freedom to implementations to make things elegant in their particular languages.What about having an appending, that's non-normative and not required for RFC compliance, that describes suggested conveniences, such as "properties.pre

Re: [Taps] On Profiles for TAPS Preconnections

Yes, I would be happier with suggesting something like TransportProperties.WithProfile(profile), rather than replacing the primary constructor. To the point of trimming down the API, I do think that it may be good to only choose one between options like this: * properties.prefer(property) * pr

Re: [Taps] On Profiles for TAPS Preconnections

I wonder if this argument is more because at the moment profiles are handed over as a parameter on creation of the properties and not about the existance of properties in general. Maybe another solution would be a call along the lines of TransportProperties.WithProfile(profile) , similar to what we