Subject: [MMUSIC] Re: ICE: Comments on draft-ietf-mmusic-ice-02.txt

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

Magnus,

Thanks for these great comments, most were incorporated in the -03 draft 
which you can find at:

http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt

inline for more.

Magnus Westerlund wrote:

> Hi Jonathan,
> 
> I have reviewed your latest ICE proposal and have some comments that I 
> don't think are in direct relation to the open issues you have presented.
> 
> 1. Section 4. page 8, third paragraph:
> "This would
>    typically be a TURN derived transport address, as it is most likely
>    to work with unknown non-ICE peers."
> 
> Is this really true. I would say it may be true for a client in a 
> private network. I don't think it is appropriate to make this statement. 
> I would say that it is highly dependent on the situation. One may have 
> public IP addresses, like most of us Swedes, but still need to run ICE 
> to allow others to get their connection correct.

It is indeed problematic. More text has been added to discuss this. 
There is no cure-all here; the TURN public address is still your best 
bet, but it won't always work.

> 
> 2. Section 5.1.1, fourth paragraph:
> "Each
>    alternate element conveys a transport address for RTP, one for RTCP,
>    a STUN username fragment and STUN password. "
> 
> What is the reason to not have separate user and passwords for RTP and 
> RTCP. They are separate channels, and one needs to ensure that a RTP 
> channel is not mapped to RTCP. If my understanding of ICE is correct, 
> the only way to ensure this is to use different usernames.

Yes. This was a bug. Usernames and passwords are required for both. The 
syntax now expresses that, and there is text explaining this.

> 
> 3. Section 5.3.1: Fourth paragraph:
> "These protocols work by having the client send, from a specific local
>    transport address, some kind of message to a server."
> 
> I think it might be clear if one replace "These" with "UNSAF".

fixed.

> 
> 4. Section 5.3.2: I am not comfortable with the notion to use the STUN 
> username to determine that it is STUN request. This will make all other 
> packets ending up in media protocol.

I don't follow this. We've discusssed this issue a bunch. The resolution 
proposed in this draft is that the transport address first listen for 
STUN, and then once an RTP packet is received, it switches to RTP.

> 
> 5. Section 5.3.2: page 14:
>   "The username fragment MUST be globally unique, so that no other host
>    will select a username with the same value."
> 
> My question is how you ensure this. You haven't specified a mechanism to 
> ensure that all clients will produce globally unique user names. I think 
> it is clear that one can produce randomly selected usernames that are 
> extremely likely to be unique, however to guarantee it seems impossible.

A proposed algorithm is provided, and the requirements say it needs to 
be unique with high probability.

> 
> 6. Section 5.3.3: Page 15,
> "If a user is a telecommuter, and therefore connected to their
>    corporate network and a local home network, they may prefer their
>    voice traffic to be routed over the VPN in order to keep it on the
>    local network when communicating within the enterprise, but use the
>    local network when communicating with users outside of the
>    enterprise."
> 
> I think the "local" on third line from the end, should be "corporate" 
> instead.

fixed.

> 
> 7. Congestion control:
> I think we will need to work out how congestion control should be 
> handled. In fact I think the initial full mesh STUN check can actually 
> be sufficient to force some low bit-rate networks into congestion. For 
> example, if I would connect my laptop with all its interfaces, and get 
> all sorts of different IP address that I could. I would think I would 
> end up with 4*4=16 different sourceable interfaces, and that is without 
> using any UNSAF mechanism, only the two IP versions and VPNs. Point is 
> that a peer can easily have around 10 announce addresses. If the other 
> peer then are going to try them in parallel and totally ignores to limit 
> the request rate, all 10 STUN request could go in a very short time. 
> This could easily congest the network, if the interface used is for 
> example a GPRS link, or something similar low bit-rate.
> 
> I do also agree with your later concerns over the timers. I think there 
> is need to figure out how to ensure that this scales and does not cause 
> congestion. Both in the simple case of the retry timer, and the quick 
> recovery method.

The timers have mostly been removed; there are no mid-session checks.

However, there is still an initial burst of connectivity checks. This 
seems like it would be very hard to do otherwise. We haven't sent 
anything on the network yet, so we don't know its transport 
characteristics to do any congestion control. If we try a slow 
exponential ramp up, it has a huge, and IMHO unacceptable impact on call 
setup. As such, I think we should leave it as is.

> 
> 8. Section 5.3.4, page 19: What is FSM? You don't spell it out.

Finite State Machine. Now expanded.

> 
> 9. Section 5.3.4, Figure 3:
> In the error/set retry timer transition from HANDSHAKING to BAD, isn't 
> the most likely case, that the giveup timer expires?

yes

> 
> 10. Section 5.3.4: page 20, second paragraph: Have you forgotten to 
> consider packet loss. I would think that packet loss would be likely 
> reason for the failure.

yes, though it would have to be over an extended duration - 9s for the 
stun transaction to timeout.

> 
> 11. Section 5.3.4: page 20, last sentence: Do you really intended the 
> refresh timer to be 1 second. That seems all to frequent to keep the 
> bindings alive, and ensuring that connectivity.

This timer is gone.

> 
> 12. Section 5.3.4: page 21, first paragraph: I think there is some need 
> to some consideration period before switching from Good to BAD. With the 
> current proposal it seems this will happen on the first packet loss the 
> STUN traffic encounters. I think it needs to be a bit more robust. I 
> think one can also to this state consider to take input from the 
> transport protocol sending media over the address combination.

This transition is gone now.

> 
> 13. Section 5.3.5, "Assuming the USERNAME is valid, the client MUST 
> generate a STUN response per RFC 3489."
> 
> Isn't a valid password also required?

yes. Thi s paragraph has been reworded.

> 
> 14. Section 6.1: last sentence:
>  "However, once one of the clients begins receiving media
>    on its STUN derived address, it can deallocate its TURN resources."
> 
> Is the above really a positive thing in ICE. If a peer has announced its 
> TURN address, shouldn't it keep it around. As I understand it can't be 
> deallocated by the other peer, so it will keep trying it. So the turn 
> address would always be in BAD state. Also having it around provides 
> fail over possibilities.

The spec says you SHOULD keep them, but often there is no need. The case 
yo are worried about won't happen. They can only be de-allocated when a 
higher priority transport was contacted and used. Unless you do 
re-invites in the sip case, you won't ever receive packets on them.

> 
> 15. section 9: I think the SDP attribute name could be better selected. 
> I don't think "alt" is really a good name for ICE address elements. Even 
> a=ice would seem better.

It is now a=candidate.

> 
> 16. Section 9. The syntax for the attribute seems broken in two ways:
> 
> There is a missing separator between the RTP and RTCP address, I think 
> it should read:
> unicast-address SP port [SP unicast-address SP port]
> 
> Secondly the syntax element:
> derived-from  = ":" / id
> 
> is not used.

fixed.

> 
> 17. Section 9:
>   "If the ICE message indicates an RTCP address and port that are not
>    one higher than that of the RTP, the SDP RTCP attribute [2] MUST be
>    used to convey them."
> 
> Shouldn't this include the word "default" and read like this:
> 
> If the ICE message indicates an default RTCP address and port that are 
> not one higher than that of the RTP, the SDP RTCP attribute [2] MUST be 
> used to convey them.

I don't think default is needed; there is no default defined in ICE.

> 
> 
> 18. Section 9. In regards to my above comment number 2. I think the 
> attribute should clear separate RTP and RTCP addresses and allow for 
> individual username and passwords.

done.

> 
> 19. Reference 12, need to include the standard number STD 64.

xml2rfc does what it does. I can't fix this.

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