Group management

[mwelzl]

Connections must, of course, have a group number. (It's just not written anywhere yet. A group number should be generic Connection property, in Section 9.1.) Otherwise, how could one know which Connections are grouped and which are not? And they may be grouped in different ways - one can have a group of 2 Connections, and another group of 3, and then priorities apply only among the Connections in each respective group.

So far, not a big deal, I guess.... now comes the "this really only existed in Michael's mind" part:

These group numbers should not only be readable: on Preconnections, they should be writable as well. This, then, expresses a wish to have certain Connections automatically grouped and some not. The semantics should be: same number = they are regarded as "grouped", but there is no guarantee that they really are muxed, i.e. streams of one underlying transport connection (e.g. SCTP Association). Different number = they are NOT grouped and never will be.

ISTM that, with this construct, the only point of the Selection Property "Multistream Connections in Group" is to be able to tell this wish for stream muxing early, when only one Preconnection has been created. Else one could create multiple Preconnections and give them the same group number, and that would convey the same wish. But I guess requiring "you want multi-streaming: you must create multiple Preconnections before calling init" is a hassle.

[abrunstrom]

Ok, I am confused now, we have clone for this purpose, no? Connections that are cloned are grouped (get the same group numnber)?

[mwelzl]

but they may also get grouped automatically, without a call to clone. Only with clone, how do I say that I don’t want certain Connections to be grouped?

…

Sent from my iPhone

On 8 Feb 2019, at 17:02, abrunstrom ***@***.***> wrote: Ok, I am confused now, we have clone for this purpose, no? Connections that are cloned are grouped (get the same group numnber)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[abrunstrom]

Really? Where is this described? Not sure that is a good idea.

[mwelzl]

I thought the right place to describe it would be the implementation draft; I don't think it's there yet. However, I also don't believe we have any text contradicting it.

minset made the argument that the only aspect of multi-streaming that involves application-specific knowledge (knowledge that only applications have, i.e. something that really must be under application control) is prioritization between groups of streams. We have that in the API. But the decision on whether a Connection becomes a stream or not isn't really relevant to applications.

...except, of course, if they care about what goes on in the network - e.g. multiple 5-tuples could be routed differently, etc. etc. ... or you may want to be compatible with a peer that doesn't work with this kind of mapping. So, it must be possible to disable this, but note that this is a case of an application doing protocol-specific stuff (e.g., designed to talk to a "normal" SCTP server). Necessary to support but not the main design direction.

The whole point is to try to automate network optimizations and put them below the API. So, IMO, the right design is to allow for automatic mapping of Connections to streams, and even encourage doing this by default if possible. What can be wrong about that, when it can be disabled anyway?

[abrunstrom]

When you call clone the connections are grouped. It is up to the implementation to decide if it becomes a stream or not. If you do not want them to be grouped you need to set up a second connection using a new Preconnection. This covers the two cases, so I do not understand why we would need anything more? I do not disagree with any of what you write above, but the automatic mapping to streams only applies within a connection group, right? Maybe I have misunderstood what this issue is about?

[mwelzl]

Ah, I see. Well I guess it's more a syntactical issue - as a developer, it seems that "clone" is something one really has to think about before deciding to do it, and if one doesn't care much and "just" wants a Connection, it's not the most obvious call to make. I'd like to have cloning be the default behavior somehow, with a way to opt-out rather than to opt-in.

Maybe it's enough to put explicit text around the "init" calls, saying that these are intended for trying to reach a destination for the first time, and that Clone should normally be the preferred choice for multiple Connections?

[gorryfair]

I mcuh prefer the latter - we don't even need to say "intended" --- you could just say that most apps will benefit from the advantages this gives them.

Gorry

[mwelzl]

Ok; convinced. Seems like, in typical Michael style, I created "much ado about nothing" here.

[abrunstrom]

Cloning is also easier than setting up a new preconnection and again populating it with your preferences, so should be simpler for the app developer.

[mwelzl]

Also true...

[mwelzl]

To conclude: @abrunstrom convinced me that this issue is a non-issue. I should have closed this long ago.