Re: [MMUSIC] ICE offer/answer terminology

> On 10 Jun 2015, at 20:36, Ari Keränen <ari.keranen@ericsson.com> wrote:
> 
> 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)")
> 
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

> 
> 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
>> 
> 