Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 1 Aug 2013 08:19:47 +0000

Hi,

I want to revisit a discussion from an earlier version of the draft. 

An earlier version of the draft suggested to do IPv4 and IPv6 checks in parallel. I like that idea because:

1. It really speeds up the connectivity check phase
2. Should have no impact on the NAT port allocation problem. (Or is there a way for an IPv6 conn check to have a negative impact on the IPv4 NAT?)
3. Easy to implement. I would just change the way I traverse the the ordered checklist. Send first available IPv6 test, then search the list for the first available IPv4 check. To avoid timing issues a ice-option might be used to say that the checklist is done in parallel if it contains different address types. (Do we want to support IPv7.. :-) )

.-.
Pål-Erik

On Jul 31, 2013, at 18:16 PM, Martin Thomson <[email-masked]>
 wrote:

> On 31 July 2013 17:56, Ari Keränen <[email-masked]> wrote:
>> overly complex
> 
> Yes.  Given that this is a very small part of a spec that already fits
> that description, we need to be careful.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Aug 2013 13:26:29 +0200

> An earlier version of the draft suggested to do IPv4 and IPv6 checks in parallel. I like that idea because:

I don't think that that is necessary.

> 2. Should have no impact on the NAT port allocation problem. (Or is there a way for an IPv6 conn check to have a negative impact on the IPv4 NAT?)

I can think of a way that this would be bad, but I'm only speculating
about NAT implementation in doing so.

> 3. Easy to implement. I would just change the way I traverse the the ordered checklist. Send first available IPv6 test, then search the list for the first available IPv4 check. To avoid timing issu…

I don't believe that this is any easier to implement.  In fact, the
easiest thing to implement is a change to the priority calculation.
Besides, a priority change will actually cause the checklist ordering
to be the same without new signaling, anything else won't.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 1 Aug 2013 04:40:56 -0700

> 1. It really speeds up the connectivity check phase
[BA] Not if the constraints on sending of connectivity checks are still operative. 
> 2. Should have no impact on the NAT port allocation problem. (Or is there a way for an IPv6 conn check to have a negative impact on the IPv4 NAT?)
[BA] There are (pathological) cases where a host with an IPv6 address may find that it has an IPv4 reflexive address (NAT64). 
> 3. Easy to implement. 
[BA] Given that there are now tens of millions of deployed hosts running ICE based on RFC 5245, "ease of implementation" of non-backward compatible extensions should not be a criteria.  A more relevant question is "can this problem be solved in a backward compatible way?"  In this case, I believe that the answer is Yes.   Given that, there is neither a need nor a compelling case for breaking backward compatibility.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 1 Aug 2013 07:50:35 -0400

> about NAT implementation in doing so.

Presumably a check on a Teredo candidate impacts your IPv4 NAT.

--
Jonathan Lennox
[email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 2 Aug 2013 15:11:16 +0000

> -----Original Message-----
> From: Ari Keränen [mailto:[email-masked]]
> Sent: Wednesday, July 31, 2013 9:26 PM
> To: Jonathan Lennox
> Cc: Tirumaleswar Reddy (tireddy); [email-masked]; Martin Thomson
> Subject: Re: [MMUSIC] RFC 5245 Section 4.1.2.1, ice-happy-eyeballs and ICE bis
> 
> On 7/31/13 4:45 PM, Jonathan Lennox wrote:
> >
> > On Jul 31, 2013, at 4:13 PM, "Tirumaleswar Reddy (tireddy)"
> <[email-masked]> wrote:
> >>
> >> Using the formula in RFC 5245
> >>
> >>    priority = (2^24)*(type preference) +
> >>               (2^8)*(local preference) +
> >>               (2^0)*(256 - component ID)
> >>
> >> Type preference of
> >>   Host candidates > Server-reflexive candidates > Relayed candidates
> >>
> >> (For example host candidate is 126, server-reflexive 105)
> >>
> >> that causes the problem that when candidate pair priority is calculated
> (priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0))
> >> The candidate pair IPv4 (host, server-reflexive) will only be tested only
> after all IPv6 host candidate-pairs, IPv4 host candidate pairs.
> >>
> >> Even if policy table RFC 6724 is changed so that IPv4 addresses have higher
> precedence that does not solve the problem, It will still result in IPv4
> (host, server-reflexive) to be tested only after all IPv4 host candidate
> pairs, IPv6 host candidate-pairs.
> >>
> >> Hence during the WG session, I had explained that by tweaking the candidate
> priority will not solve the problem, but the candidate pair priority has to be
> adjusted after offer/exchange such that after NNN number of preferred IPv6
> candidate pairs the highest-priority IPv4 candidate-pair is tested and the
> above adjustment continued until all candidate pairs of the preferred address
> family are exhausted.
> >
> > The first formula you quote is the one that RFC 5245 defines as recommended,
> not mandatory.  What we're suggesting be changed is not the "local preference"
> field, but actually the calculated 32-bit "priority" field for the candidate.
> You can set your priorities such that some server-reflexive candidates have
> higher priority than some host candidates, and the calculation of the pair's
> 64-bit priority will still work.
> >
> > We need to be pretty careful when defining a new formula for how these
> priorities are set, though.
> 
> If it's only about updating that formula, this indeed looks like a good
> way forward.
> 
> Just need to think how to get all we want to express (and what do we
> actually want to express) in a priority formula that isn't overly
> complex. Expressing things like "some IPv4 host-srvrflx should be
> prioritized over (some) IPv6 host-host but v4 host-host below (some) v6
> host-host" etc may get a bit messy.

How about using the existing recommended formula in RFC 5245 and after the local candidates are prioritized do the following additional steps :
 
a.  If the first 'N' candidates are of the same IP address family, then the highest-priority candidate of the other address family is promoted to position 'N' in the list.

b.  Step b is repeated for rest of candidates. This is continued until all candidates with the preferred address family are exhausted.

This would work even when policy table is modified such that IPv4 addresses have higher precedence than IPv6 using DHCP http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10. 

--Tiru.
> Cheers,
> Ari

---

From: Martin Thomson <[email-masked]>
Date: Sat, 3 Aug 2013 08:47:56 +0200

> This would work even when policy table is modified such that IPv4 addresses have higher precedence than IPv6 using DHCP http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10.

I'm not sure that your specific formulation of the algorithm makes
sense (reread step b), but I think that the general principle you use
in the draft (as you explained in the WG meeting) is certainly a
viable option.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 3 Aug 2013 19:56:18 +0000

> From: Martin Thomson [mailto:[email-masked]]
> Sent: Saturday, August 03, 2013 12:18 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Ari Keränen; Jonathan Lennox; [email-masked]
> > a.  If the first 'N' candidates are of the same IP address family, then the
> highest-priority candidate of the other address family is promoted to position
> 'N' in the list.
> >
> > b.  Step b is repeated for rest of candidates. This is continued until all
> candidates with the preferred address family are exhausted.
> >
> > This would work even when policy table is modified such that IPv4 addresses
> have higher precedence than IPv6 using DHCP http://tools.ietf.org/html/draft-
> ietf-6man-addr-select-opt-10.
> 
> sense (reread step b), 

Typo; what I meant was

b. Step a is repeated for rest of the candidates until all candidates of the preferred address family are exhausted.

> but I think that the general principle you use

--Tiru.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 13 Aug 2013 23:46:42 +0000

On Jul 31, 2013, at 8:34 AM, Martin Thomson <[email-masked]> wrote:

> This formula is just a recommendation (a SHOULD, to be fair)

I think you need to read 2119 and understand the analysis was done when designing ICE and came to the conclusion there were order of checks needs to be coordinated between the two sides. 

(I'm not saying that we can't find a way to improve on 5245, I'm just saying pretending you can ignore it because it has a SHOULD won't work)

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 13 Aug 2013 23:46:38 +0000

On some NATs it was clear that from the source code that the rate limit was caused by how fast the NAT could actually create new connections and it was the same code path for all address families. So at least in some cases, the fact that the address family changed does not speed up the number of mapping per second the NAT can create. Hard do know how general this is. 

Jonathan's Teredo point is very insightful.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Aug 2013 01:15:54 +0100

> I think you need to read 2119 and understand the analysis was done when designing ICE and came to the conclusion there were order of checks needs to be coordinated between the two sides.

I think that you misunderstand.  That particular requirement is
addressed by a MUST in Section 5.7.2
(http://tools.ietf.org/html/rfc5245#section-5.7.2), which provides the
ordering guarantee.  The text in 4.1.2.1 uses SHOULD, and I'm aware of
implementations that choose not to follow this guidance for the exact
same reasons that this draft (the eyeballs draft, that is) was
created.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 14 Aug 2013 00:32:26 +0000

Sorry, thought you were talking about the other thing.