Subject: [MMUSIC] bundle-11: Bundle Address Synchronization (BAS)

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 9 Oct 2014 15:08:11 +0000

Christer, Cullen, Harald, all

Bundle Address Synchronization (BAS) is motivated by almost the same arguments that led to the ICE updated offer/answer in 5245.

Now, at IETF 90 the updated offer/answer procedures for ICE were discussed and the consensus was to change the existing behavior to:
" you do it (i.e. the updated offer/answer) or don't do it, but you indicate in the o/a if you're going to do it. Basically want to have option to never do the updated O/A exchange, with an indication in the signaling that you will not be doing it. Of course can always initiate a new O/A exchange whenever you want to."

I think the same discussion and obviously  its result also applies to BUNDLE and BAS.
Otherwise, if you use BUNDLE together with ICE, the updated offer/answer cycle is back.
If the WG agrees, this would require some additional parameter/attribute in the offer that indicates if BAS will be performed or not.

Some common approach for the updated offer/answer issue might also be justified.
An obvious thought  would be if re-using the same "thing" for ICE and BUNDLE would be appropriate.
... and for CapNeg albeit its lack of deployment
Thoughts

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Oct 2014 18:41:19 +0000

Hi,

>Bundle Address Synchronization (BAS) is motivated by almost the same >arguments that led to the ICE updated offer/answer in 5245.
>
>Now, at IETF 90 the updated offer/answer procedures for ICE were discussed >and the consensus was to change the existing behavior to:
>" you do it (i.e. the updated offer/answer) or don't do it, but you indicate in >the o/a if you're going to do it. Basically want to have option to never do the >updated O/A exchange, with an indication in the signaling that you will not >be doing it. Of course can always initiate a new O/A exchange whenever you >want to."

Actually, that consensus is still to be confirmed on the list...

>I think the same discussion and obviously  its result also applies to BUNDLE >and BAS.
>Otherwise, if you use BUNDLE together with ICE, the updated offer/answer >cycle is back.
>If the WG agrees, this would require some additional parameter/attribute in >the offer that indicates if BAS will be performed or not.
>
>Some common approach for the updated offer/answer issue might also be >justified.
>An obvious thought  would be if re-using the same "thing" for ICE and >BUNDLE would be appropriate.

In general, I prefer a negotiation model, rather than the sender indicating that it is going to do something - without the receiver being able to impact that.

Because, in case of the updated offer (no matter whether it's ICE or BAS), it is often the receiver (or some intermediary) - not the sender - that knows whether it's needed or not.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 9 Oct 2014 19:35:13 +0000

From: Christer Holmberg [mailto:[email-masked]]
Sent: Donnerstag, 9. Oktober 2014 20:41
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: Bundle Address Synchronization (BAS)

Hi,

Actually, that consensus is still to be confirmed on the list...
[TS] Well, according to the minutes my understanding is that the chairs already declared consensus.
But that's chair's business where I don't want to interfere.

In general, I prefer a negotiation model, rather than the sender indicating that it is going to do something - without the receiver being able to impact that.
[TS] I wouldn't necessarily object to having such a negotiation but it adds complexity.
Apart from the additional complexity, the question to answer in that model however is: "What is the fallback if negotiation fails?"
Is it "do the extra offer/answer" or "omit the additional offer/answer"?
My preference would be omitting. Therefore, I can live quite well with the IETF 90 outcome.
Others might prefer doing the extra offer/answer.

Because, in case of the updated offer (no matter whether it's ICE or BAS), it is often the receiver (or some intermediary) - not the sender - that knows whether it's needed or not.
[TS] Well, the receiver is free to send a new offer anytime. However, I have issues with intermediaries that interfere in such a negotiation.
Consider the case where you have two of them and both have different preferences.

Regards
Thomas

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Oct 2014 21:47:21 +0000

Hi,

It is the receiver, not the sender, that possible needs the second offer. So, while I agree a negotiation may not be needed, I think we should at least let the receiver decided whether the offerer should send it or not.

Regards,

Christer

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 13 Oct 2014 08:31:47 +0000

inline

From: Christer Holmberg [mailto:[email-masked]]
Sent: Freitag, 10. Oktober 2014 23:47
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: Bundle Address Synchronization (BAS)

Hi,

It is the receiver, not the sender, that possible needs the second offer. So, while I agree a negotiation may not be needed, I think we should at least let the receiver decided whether the offerer should send it or not.
[TS] I think it is crucial having this aligned for BUNDLE and ICE.
However, for ICE the consensus on updated offer/answer handling was different and I think it is the better approach.
Both sides, sender and receiver, might have their reasons why they want to send the update or omit the update.
Prescribing what the other end must do can easily conflict with these reasons and lead to unwanted side effects.
Thus I still prefer this approach as discussed in IETF90 "The offerer/sender  says what is does". The sender can then react as it needs.
Regards
Thomas

Regards,

Christer