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

["Pal Martinsen (palmarti)" <[e-mail]>]

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