Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

So, would anyone object to the principle of going forward with an ID approach?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: 7. maaliskuuta 2016 0:46
To: Justin Uberti
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

On 3/3/16 7:35 PM, Justin Uberti wrote:
>
>
> On Thu, Mar 3, 2016 at 4:12 PM, Paul Kyzivat <pkyzivat@alum.mit.edu 
> <mailto:pkyzivat@alum.mit.edu>> wrote:
>
>     On 3/3/16 6:23 PM, Roman Shpount wrote:
>
>              Assuming you are comfortable with the above, I think the
>         indicator
>              we want is some sort of “connection-id” parameter, either as a
>              standalone value or as a value which is unique in
>         association with
>              the fingerprint. This seems cleaner than having a “new” versus
>              “reuse” token. The semantics would be that if you see a new
>              identifier that means you need to form a new association
>         but that
>              multiple replays of the same identifier mean that you reuse
>         the same
>              association (i.e., do not DTLS reconnect).
>
>
>              This resolves the idempotency concern that present with the
>         existing
>              proposal, and also makes backwards compatibility simpler; a
>         change
>              in either a=fingerprint or a=dtls-connection-id will
>         trigger a new
>              DTLS connection.
>
>
>         I have actually proposed this very thing (dtls-association-id
>         instead of
>         dtls-connection), but people on the list found this to be too
>         complex.
>         This has an additional benefit of handling some of the 3pcc use
>         cases
>         when in response to empty INVITE it is unknown if generated
>         offer will
>         be used in the same session or in the new one. dtls-association-id
>         resolves this nicely, but we settled for a simpler requirement
>         to always
>         respond with a=dtls-connection=new in response to empty INVITE.
>
>         The question is does group feels strongly about changes to
>         (dtls-association-id from dtls-connection at this late stage,
>         since this
>         will require a major rewrite.
>
>
>     I had discomfort with connection=new/existing back when it first
>     came up with TCP, exactly because it isn't idempotent. I don't
>     recall why I lost that battle.
>
>     But now that is water over the dam. So I think it takes a stronger
>     argument for why to adopt a different pattern now for something so
>     similar. If the SDP implementation already has to deal with this for
>     a=connection, then why is it a problem to also do so for
>     dtls-connection?
>
>
> I don't agree that the ship has sailed on this.

I agree. (Their is a lot of *water* over the dam, but the ship hasn't gone over the dam yet.:-) I just said the bar was higher than normal.

> If we unearth a
> compelling reason (idempotency), we shouldn't be bound by decisions to 
> a different attribute made 10+ years ago.
>
> Besides idempotency, the connection/instance id approach has the 
> additional benefit of simpler logic for old remote endpoints - if 
> either the fingerprint or id changes, make a new DTLS connection.

The tradeoff is that it becomes a *new* mechanism. More opportunities for people to misunderstand and get it wrong. More opportunities for us to write the description unclearly to help with that.

	Thanks,
	Paul

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic