Subject: [MMUSIC] summary of resolution of old ICE open issues

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Oct 2004 01:54:55 -0400

Folks,

Last August, we had some threads on open issues in ICE. This note
summarizes the resolution to each of these in the recently updated -03
document.

Issue 1: v6trans applicability
> Currently, the ICE spec describes its usage in facilitating the 
> transition to v6. It points out two possible usages. The first is for
>  dual-stack hosts, to allow them to advertise addresses for both v4 
> and v6, and then use the one which has connectivity. Another one is 
> for hosts with both v6 native and 6to4 addresses, to detect if native
>  v6 connectivity exists.
> 
> The open issue is, are these valid and useful usages? Are there other
>  ones? This isn't so much as an open issue, as it is a "todo", where 
> the "todo" is to vet this with some folks from v6ops. As such, any 
> thoughts or inputs here are welcome. I will try to seek some input 
> while I'm at ietf as well.

I havent gotten feedback yet, but I believe the applicability is correct.

Issue 2: processing STUN requests before the accept
> Consider the following scenario.
> 
> User A sends an ICE initiate message (i.e., SIP INVITE with SDP). It
> contains the username fragment contributed by user A. THis arrrives
> at the called party, user B. User B sends an ICE accept message
> (i.e., a 200 OK with an SDP answer). This contains the username
> fragment contributed by user B. User B, in parallel, sends a STUN
> request to user A. THat request has a username, and the username is
> the concatenation of the two username fragments. Most likely, this
> STUN message will beat the accept message (the 200 OK) back to user
> A, and be rejected. This case is handled in the spec by having user B
> retry (although this is far from obvious and needs to be clarified).
> 
> However, another behavior is possible. Instead of rejecting it, user
> A could accept these STUN requests, so long as the first half of the
> USERNAME matches the fragment sent by user A in its initiate message.
> However, until the accept message is received, user A won't be able
> to correlate the source of that stun request with the IP/port/STUN
> username fragment/password of its peer, and thus won't be able to
> generate its own stun request back to the source of the incoming stun
> request. It could cache the source IP/port of the stun request if it
> were new, and then gather the information later when the accept
> message arrives. However, this increases complexity.
> 
> What do we gain by having the user accept the stun request? Slightly
> faster operation, since the called party (user B) may be able to do
> its stun connectivity checks even before the 200 OK reaches the
> caller.
> 
> So, the open issue is, do folks want to allow user A to  accept these
> STUN requests before the accept message?
> 
> I'm on the fence somewhat, but probably would vote for no.

There seemed to be agreement not to allow this. -03 disallows it.

Issue 3: timer settings
> Currently, the ICE spec uses a number of timers to control how
> frequently a STUN transaction should be re-attempted to verify the
> current state. These timers are:
> 
> Refresh timer: While in the GOOD state, when to try again to verify
> that its still GOOD? Default: 5s
> 
> Rapid Retry timer: While in the HANDSHAKE state, when to try again
> while you wait for your peer to get the accept message and generate
> its STUN packets to open permissions? Default: 1s
> 
> Giveup Timer: While in the HANDSHAKE state, when to give up, and
> assume the address is no good. Default: 50s
> 
> Retry Timer: while in the BAD state, when to retry to make sure the
> address is still BAD. Default: 60s
> 
> 
> 
> The timer that needs the most work is the refresh timer. I think that
> this should probably be a fraction of the bandwidth of the media
> traffic, as a lower bound, just like RTCP.
> 
> The real issue is what to do in failure cases. THe spec currently
> says that, if the client should find that its addresses are all in
> the BAD state all of a suddent, to push them all into the INIT state
> and try to recover. This is meant to deal with a failure of a nat in
> the middle of a call that wipes out all of the bindings. Now, whilst
> a rapid recovery behavior is good here, it can lead to real problems
> if the cause of the failure was NOT a NAT failure, but congestion. In
> that case, the response to the congestion loss is to send more
> packets - i..e, STUN requests. Thus, some kind of careful retry and
> backoff approach is needed. The alternative is to simply not do this.
> 
> 
> To summarize, the open issues are:
> 
> 1. Are the timers properly set, and should we define a lower bound on
> the refresh timer as a fraction of the media bandwidth (I say yes)
> 
> 2. How should we handle the case where all of the addresses enter the
> BAD state? Should we support this reconnect mode?

This issue is mostly resolved by removal of the mid-session checks.
There are still two timers. One controls the gap between STUN
transctions in the HANDSHAKE state, which is 50ms (this is NOT the
interval between packets - it is the interval between transaction
attempts), and a timer for giving up in the handshake state, which is
60s. I think these are fine.

Issue 4: TCP applicability
> Currently, ICE is mostly worried about media streams over UDP. For
> TCP, the problem is less severe, but it does exist. The connectivity
> checks are certainly much easier in the TCP case; the ability to set
> up a connection represents a valid connectivity check. Its not clear
> that STUn should be sent within the connection. The framing and demux
> are more complex for TCP than UDP.
> 
> So, the question is, what, if anything, should ICE say about TCP?
> 
> Here is my proposal:
> 
> ICE should be applicable to TCP. In particular, an initiator or
> responder can send messages that include alternates for TCP streams.
> However, the connectivity checks would not be done using STUN.
> Rather, they would be done using something thats media specific. The
> initial check is easy - the successful establishment of the
> connection. Subsequent checks would be done using something that is
> specific to the media. It *could* be stun, but that would be
> specified by someone else.
> 
> ICE also specifies that, when a client receives a request, it checks
> the source IP/port and considers that a candidate too. I don't think
> that behavior really makes sense for TCP. If I receive a connection
> setup (i.e., SYN), the resulting connection could be used to send
> data to my peer. There is no point in trying to establish a
> connection to that source IP/port.
> 
> I think that this works well with comedia, where a passive or actpass
> endpoint would list alternates where it can be reached. Once the
> connection is established, one cannot anyway open one in the reverse
> direction.
> 
> Do folks agree with this proposal?

There was mixed opinions on this. Colin made what i felt was the most
convincing argument - the industry need is for UDP. Lets solve that
first and worry about other things later. Since TCP clearly differs, it
would complicate an already complicated protocol even further. So, TCP
is not treated in -03.

Issue 5: alt parameter
> At a previous meeting, it was mentioned that 3gpp had defined their
> own SDP parameter called "alt", creating an overlap in the
> specifications. One of the specs needs to change, as a result.
> However, I am not sure what 3gpp spec it was that used "alt", and
> whether it was still proceeding. Indeed, in such a conflict, its not
> clear who should move off the parameter name. I would think that IETF
> would get priority in such cases.
> 
> Anyway, the issue is whether we should change the name or not. I'm
> hoping that someone can provide a reference for the 3gpp spec, and/or
> can provide an update on its status.
> 
> I'd prefer to not change the name; there are already multiple
> implementations of ICE out there..

Folks wanted to change it for the most part. So, it is now "candidate".
This results in a complete break in compatibility with past revs of the
draft :(

Issue 6: non-STUN connectivity checks
> The ICE specification uses STUN, multiplexed within the media stream,
> as a form of connectivity check. STUN was chosen originally since, in
> addition to providing a check, it also told the client about its
> source IP/port as seen by the server. However, in this latest rev of
> ICE, the client does not need to learn its IP/port as seen by the
> server. The STUN server itself (which is embedded in the peer in the
> call) uses the source IP of the STUN request as a new potential media
> destination.
> 
> Since the primary feature provided by STUN is no longer required, it
> begs the question about what features we do need, and whether STUN
> remains the ideal choice. Here are the functions we need from any
> connectivity check protocol:
> 
> 1. One side sends a packet to the other which generates an immediate
> response
> 
> 2. The response gets back to the originator with high probability,
> informing the sender that their original request was received
> 
> 3. The request conveys the source IP/port to the recipient (pretty
> much any IP protocol gives us this)
> 
> 4. The request can contain some kind of correlation tag, allowing the
> recipient to correlate it as coming from an IP/port advertised in an
> SDP offer or answer
> 
> 5. The request can contain a unique identifier, provided by the
> client, so it can be sure that the connectivity request was generated
> in response to the SDP offer or answer it sent.
> 
> 
> Clearly, STUN meets these requirements. (1) is met because it
> generates a response immediately, (2) is met because STUN is reliable
> due to client retransmits, and the response goes back to the source
> IP/port, (3) is met easily, (4) is met by using one half of the
> USERNAME, and (5) is met by using the other half.
> 
> Now, it is possible for other things to work. In particular, RTP
> itself might work:
> 
> (1) We could make use of an immediate RTCP packet sent in response to
> an RTP packet. I believe the RTP no-op proposal had a flag for
> signaling this. However, RTCP might fail because its sent to a
> different IP/port, thus it is not as reliable as STUN.
> 
> (2) We could implement a retransmit strategy ontop of RTP to get
> reliability
> 
> (3) is met
> 
> (4) We could use the approach described in
> http://www.ietf.org/internet-drafts/draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt,
> which allows each side to signal its own half of the SSRC, and then
> use one half for the sender correlator
> 
> (5) the other half provides the unique identifier
> 
> 
> So, what to do here? The options I see are:
> 
> 1. keep it STUN only as specified, 2. allow for multiple mechanisms,
> define STUN now, mandate STUN as baseline, and see what happens to
> the ssrc demux mechanism, specifying it as an alternative down the
> road 3. drop STUN completely, move to RTP with the immediate RTCP
> capability and SSRC demux (those would need to be specified within
> AVT)
> 
> I am inclined towards (2). I don't like (3) since it will
> substantially delay ICE, since it would depend on two mechanisms in
> AVT which don't have consensus or clear direction at all, and RTP
> doesnt work as well. I think (2) is better than (1) since the
> multiplexing of STUN and RTP on the same port is ugly, and it would
> be nice to have an out down the road if something better can be
> specified. However, we absolutely need a baseline mechanism to have
> interoperability, and STUN is that.

The current draft removes mid-session connectivity checks. Initial
checks are with STUN. Keepalvies are application dependent and done with
RTP for RTP applications. There is no way to negotiate something besides
stun in this document. I think the need for an alternative is reduced by
eliminating the mid-session checks.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic