Subject: [MMUSIC] ICEbis review (draft-ietf-mmusic-rfc5245bis-04)

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 10 Jun 2015 13:21:49 +0000

First pass. Will do a more through one later. 

Biggest change I am proposing is to ditch the offer/answer wording all together. What I think of when offer/answer is mentioned is not needed for ICE. All that is needed is a simple candidate + some info exchange.

Anyway, rest of the comments are below.

1. Introduction.
SIP and SDP is removed from the document. A more generig problem
statement regarding punching holes through two NATs are more
appropriate?

I also disagree with the statement that ICE is an extension to the
offer answer model. It does require that the agents somehow exchange
candidates, but it is nowhere as rigid as offer/answer. 

2. Overview of ICE

Do we still want to use AGENT? Or have the world moved on to endpoint?

Again ditch offer/answer move towards candidate exchange by some
signalling protocol or other means (Search and replace offer/answer
with candidate exchange may work well through out the document).

FIGURE 1. Replace STUN server with TURN/STUN Server

Some rewording of the text above the figure might be helpful. Describe
that TUNR STUN servers are use to determine what environment the agent
is operating in. 

2.1. Gathering Candidate Addresses

Two first paragraphs mixes multihomed, physical and virtual network
interfaces IP addresses and ports in a slightly confusing/wrong
way. Dual-stack is not mentioned but implied?

The sentence "If an agent is multihomed, it obtains a candidate from
each IP address." Might cause confusion? Do we need to capture that the
agent must create candidates from all available interfaces. Each
interface can have different address types and might have multiple
adresses and so on. (Maybe reference som MIF WG drafts?

Is MIP dead? Remove that as an example? Especially since ICE can
replace most of what MIP provides (With some extensions ..).

2.2. Connectivity Checks

Signaling channel or other means. Again some reference to offer and
attributes.

CHECKS = CONNECTIVITY CHECKS?

Do we need to reword the transaction. As some implementations do not
use STUN req/resp transactions, more like STUN req/resp
exhanges. I think the text here is fine.

2.5. Security for Checks

Is it worth mentioning the ufrag? For any "bad fw" that wants to do
the right thing the ufrag can be a good hint. it will have the form of
aaaa:bbbb out and bbbb:aaaa coming in the other direction. 

2.6. Concluding ICE

Some RTT drafts from TRAM might be worthwhile mentioning? Or do ww
want to get ICEbis out before that?

2.7. Lite Implementations

Do we need to give more reasons why FULL ICE is preferable? Is that
still true or do we want to embrace ICE lite as an accepted part of
the solution, not just a stepping stone?

2.8. Usages of ICE
(Offer/answer)
-> with protocols that provides a means to exchange candidates.

3. Terminology

Do readers still need to know of RFC3264?

Agent; replace with endpoint capable of exchanging candidates?

ICE offer/answer. If renaming to candidate exchange there is a good
point regarding ufrag and password exchange as well.

4. Sending the Initial Offer.

-> Exchanging Local candidates?

4.1.1.1 Host Candidates

Do we need more wording on multhiomed? I like the wording "gathered
from all IP adresses". But do we need to remember the reader that
they can come from different interfaces and might be dualstacked?

4.1.1.2

Why limit ICE agents to only use one TURN server? It should be able to
have more than one RELAY candidate without any problems? Section
4.1.2.2 implies that more than one TURN server can be used)

This section should also refer to new functionality in TURNbis, where
you can allocate a IPv4 and IPv6 candidate with one message exchange
(SSODA).

Should probably also refer to TURN server discovery draft and maybe
the new TURN auth draft as well?

Need to check if other TRAM documents affect this section as well.

4.1.2. Prioritizing Candidates

Reference Multihomed and dualstack fairness draft?

4.1.2.2 Guidelines for Choosing Type and Local Preferences

There are use-cases where RELAY addresses should not be set to
0. Services exists that provide TURN servers and then relay the
traffic through a dedicated network. 

4.2.  Lite Implementation Requirements

Link to other section that described a more generic treatment of
components?

Not sure if it good to recommend IPv4 as the default candidate? IETF is
pushing hard towards IPv6... (Probably depends on who you ask
implementors that want things to work, or standards based geeks that
want to move the standards forward)

4.3. Encoding the Offer

-> Encoding Local Candidate Information?

Reference STUNbis insead of STUN? (Not sure if anything relevant have
been updated)

5.  Receiving the Initial Offer

-> Receiving Initial Local Candidates ?

5.1.  Verifying ICE Support

More examples? If the client somehow is able to detect that some of
the candidates have been altered. 

Recommend that ICE is turned off if this is detected?

5.3.  Gathering Candidates

Somme rewording needed if we move away from offer/answer usage.
(Same for Section 5.5)

5.6.1.  Forming Candidate Pairs

Lot of SDP and RTP example. Possible to make them more generic?

5.6.3.  Pruning the Pairs

The paragraph describing that the number of connectivity checks should
be limited seems missplaced. Better moved to another section dealing
with how to send connectivity checks?

And why recomend 100? (Yes, these numbers are fun to discuss...)

5.7.  Scheduling Checks
Do we need to deal with the alternative approach regarding
transactions. We should at least keep the wording here so that webRTC
implementations do not break it. (For now this is a not, need to do
more thinking)

6.  Receipt of the Initial Answer
Usual offer/answer comments.. 

7.  Performing Connectivity Checks

No need to reference the old STUN RFC. Not heard about anyone using
it. Reference STUNbis instead of STUN?

Generally for section 7 and all sub sections; do we need to consider
wording to make it easier to implement passive aggressive nomination? 
(Just a note, need more work)

8.  Concluding ICE Processing

Somewhere here there was a gem about sending traffic, should be
highlited? (Discussed in Dallas) Or was it in Section 11?

8.3.1.  Full Implementation Procedures

Needs rewording. Not clear to me what "this section" points to. 

9.  ICE Restarts

Needs rewording if offer/answer is not used.

11.1.3.  Procedures for All Implementations

Is the talkspurt bit still in use? 

11.2.  Receiving Media

I think the SSRC discussion is to specific. Have we moved on so we can
have other protocols describe how to interact when ICE is in use, or
is this still needed?

13.  Setting Ta and RTO

I feel this could be simplified a lot. Ongoing discussions regarding
this and how to set the values?

14.  Example

Do we need to highlight TURN more? Some confusion regarding same and
Different TURN server for the agent have been known to occur. 
(Will  try to provide text.)

15.  Security Considerations

Use something else that SIPS as an example..

17.1.  NAT and Firewall Types

Do we need to mention carrier grade NATs and such? THey are a bit more
standardised, or?

17.2.1.  STUN and TURN Server Capacity Planning

Numbers need to be updated or removed

And I also think that the TURN use-case have changed a bit. Moving from
a service needed to get through the NAT to a more value add service
that have benefits beyond pure NAT traversal.

17.4.  Troubleshooting and Performance Management

Lots of SIP references. Make them more general?

Should we say something about useful ICE metrics that can be collected
from the agent. (Separate draft?)

17.5.  Endpoint Configuration

Unnecessary SIP reference?

19.2.  Exit Strategy

More SIP...

Say something regarding possible extensions. Mobility ++

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Wed, 10 Jun 2015 11:36:46 -0700

Thank you for the review Pål-Erik!

I will have a closer look at the detailed comments a bit later, but 
first let's discuss the main issue, offer/answer terminology (and hence 
the new subject for the thread).

I agree that the offer/answer as ICE terminology is not optimal since it 
implies to many that this would be RFC3264 o/a. However, we have not yet 
been able to come up with a better term.

This was also discussed at the IETF #90 MMUSIC meeting:
http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.1yc63e74pbhi

(See "Offer/Answer Terminology (slide 10)")

The consensus was roughly that we *do* have offer and answer kind of 
messages when doing ICE, calling that ICE offer/answer is a bit 
confusing, but we'll go with that unless a better alternative emerges.

What would you suggest as new terms that we could use here that would 
fulfill the requirements?

Cheers,
Ari (as individual ICE editor)

On 10/06/15 06:21, Pal Martinsen (palmarti) wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 11 Jun 2015 08:07:57 +0000

> On 10 Jun 2015, at 20:36, Ari Keränen <[email-masked]> wrote:
> 
> I will have a closer look at the detailed comments a bit later, but first let's discuss the main issue, offer/answer terminology (and hence the new subject for the thread).
> 
> I agree that the offer/answer as ICE terminology is not optimal since it implies to many that this would be RFC3264 o/a. However, we have not yet been able to come up with a better term.
> 
> (See “Offer/Answer Terminology (slide 10)")
> 
Ahhh. That was a good summary. I think I remember now.. Sorry for not checking previous discussions, but I wanted do have a “clean” read thought the document. 

> The consensus was roughly that we *do* have offer and answer kind of messages when doing ICE, calling that ICE offer/answer is a bit confusing, but we'll go with that unless a better alternative emerges.
> 
> What would you suggest as new terms that we could use here that would fulfill the requirements?
> 

Candidate exchange?

We need to have wording in there that explains there are a some more information that just the pure candidates that needs to be exchanged.

Regarding controlling/controlled we can eiter let the tie breaker fix that. Or have some wording if you are first to send the candidates you are controlling and so on. 

We should consider having the ufrag and password tied closer to the candidate. We might have missed some information when removing the medialine and session level descriptions of that. 

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Thu, 11 Jun 2015 18:16:51 -0700

> We need to have wording in there that explains there are a some more information that just the pure candidates that needs to be exchanged.

IIRC, "candidate exchange" was one proposal that was rejected exactly 
due to the fact that there is quite a bit more information than just the 
candidates that is exchanged. "ICE exchange" perhaps could be used, but 
still it would be good to be able to refer to the -- for the lack of 
better word -- offer and answer parts of the exchange.

That's why I like "ICE offer"; it implies that there is undefined amount 
of "ICE information" offered to the other endpoint which can then 
decide, based on the offer, how/if to proceed.

However, would be great to hear more opinions on this.

> Regarding controlling/controlled we can eiter let the tie breaker fix that. Or have some wording if you are first to send the candidates you are controlling and so on.

While the tie-breaker is a SIP specific feature, one argument for 
keeping the tie breaker in the generic ICE was to have easier proxy'ing 
to other ICE (SIP) domains that require this kind of check.
See: 
https://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01#section-5.2.3
(rest of the draft is pretty good read too)

> We should consider having the ufrag and password tied closer to the candidate. We might have missed some information when removing the medialine and session level descriptions of that.

Good point. However, I'm thinking that this would probably be the role 
of the usage documents to define; whether they allow multiple 
ufrag/passwords and how to handle that in the signaling.

Cheers,
Ari

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 12 Jun 2015 12:15:09 +0000

> On 12 Jun 2015, at 03:16, Ari Keränen <[email-masked]> wrote:
> 
> IIRC, "candidate exchange" was one proposal that was rejected exactly due to the fact that there is quite a bit more information than just the candidates that is exchanged. "ICE exchange" perhaps could be used, but still it would be good to be able to refer to the -- for the lack of better word -- offer and answer parts of the exchange.
> 
> That's why I like "ICE offer"; it implies that there is undefined amount of "ICE information" offered to the other endpoint which can then decide, based on the offer, how/if to proceed.
> 
ICE information exchange?

I still do like “candidate exchange” as it is pretty descriptive and cover almost everything you need to kickstart ICE.  

Ufrag and pwd is part of the candidate and affects how connectivity checks are conducted. The fact that SDP has a session level and media level set of attributes I find limiting. If I want to, I should be able to have different ufrag/pwd on each of my candidates. 

Both ICE-lite and the nomination method would not be covered by the candidate exchange wording. This should be fixable with words in the document?

Side comment regarding ICE-lite. Can this be deducted by never receiving STUN requests and only host addresses. Or can the Responses contain a ICE-lite flag to help the remote side? The importance here is that controlling side do not happen at the ICE-lite side. (ICE-lite to ICE-lite must then just rely on both offering host addresses?)

Agree with Ari, would be nice to know what others think.
This is word smithing, but somewhat important if ICE starts to get used outside the VoIP bubble. For example TAPS might need an ICE like mechanism to probe network paths.

> While the tie-breaker is a SIP specific feature, one argument for keeping the tie breaker in the generic ICE was to have easier proxy'ing to other ICE (SIP) domains that require this kind of check.
> See: https://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01#section-5.2.3
The problem occurs when you do not know who initiates the “session”. I think their might be many use cases out there where this is true.
Based on external events two agents want to communicate. They both have posted the candidates on a web page. Scenarios like that make the tiebreaker nice.

> Good point. However, I’m thinking that this would probably be the role of the usage documents to define; whether they allow multiple ufrag/passwords and how to handle that in the signaling.
> 
I am leaning in the opposite direction.. Every candidate MUST have a ufrag and password associated with it. The ufrag and password can be shared across multiple candidates. This allows the SIP usage document to say that if it is a session level attribute all the candidates have this ufrag/pwd, if it is a media level attribute all candidates associated with this medialine share the same ufrag/pwd. 

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Fri, 12 Jun 2015 11:13:22 -0700

> I still do like “candidate exchange” as it is pretty descriptive and cover almost everything you need to kickstart ICE.

And what would you call the first and second message, that are now 
called the ICE offer and answer?

I think there is some very offer/answer'ish activity happening here 
since e.g., the answer part can't add more data streams and expect it to 
work, while it can select a subset.

> Ufrag and pwd is part of the candidate and affects how connectivity checks are conducted. The fact that SDP has a session level and media level set of attributes I find limiting. If I want to, I sh…

That's a good point. I guess usually you'd end up sharing the ufrag and 
pwd across streams, but I don't see any reason why you would have to.

> Both ICE-lite and the nomination method would not be covered by the candidate exchange wording. This should be fixable with words in the document?

Any good words to propose?

> Side comment regarding ICE-lite. Can this be deducted by never receiving STUN requests and only host addresses. Or can the Responses contain a ICE-lite flag to help the remote side? The importance…

Heuristics based on having only host candidates and not receiving 
something (that could be lost due to network issues) sounds a bit flaky 
to me, so I would lean towards explicit signaling. But perhaps this 
needs a bit more thinking.

> This is word smithing, but somewhat important if ICE starts to get used outside the VoIP bubble. For example TAPS might need an ICE like mechanism to probe network paths.

Yes. Although, perhaps outside of VoIP realm the offer/answer terms are 
not that overloaded, so ICE o/a could be OK?

> Based on external events two agents want to communicate. They both have posted the candidates on a web page. Scenarios like that make the tiebreaker nice.

Agreed.

> I am leaning in the opposite direction.. Every candidate MUST have a ufrag and password associated with it. The ufrag and password can be shared across multiple candidates. This allows the SIP usag…

I'd be happy to make this clarification in the ICEbis.

Cheers,
Ari