[MMUSIC] ICE offer/answer terminology

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:
>
>
> 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
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>