Subject: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-03.txt

From: [email-masked]
Date: Fri, 10 Jun 2016 04:53:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interactive Connectivity Establishment of the IETF.

        Title           : ICE Multihomed and IPv4/IPv6 Dual Stack Fairness
        Authors         : Paal-Erik Martinsen
                          Tirumaleswar Reddy
                          Prashanth Patil
	Filename        : draft-ietf-ice-dualstack-fairness-03.txt
	Pages           : 10
	Date            : 2016-06-10

Abstract:
   This document provides guidelines on how to make Interactive
   Connectivity Establishment (ICE) conclude faster in multihomed and
   IPv4/IPv6 dual-stack scenarios where broken paths exist.  The
   provided guidelines are backwards compatible with the original ICE
   specification.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ice-dualstack-fairness/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ice-dualstack-fairness-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-dualstack-fairness-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 10 Jun 2016 12:07:12 +0000

Hi all,

This version tries to address issues during IESG review.

- Changed Intended Status to Best Current Practices
- All references are now to ICEbis not ICE. 
- Changes to reflect proposed new text in ICEbis
- Both ICEbis and this draft cross reference each other.

Proposed changes to ICEbis

Section 4.1.2.1

Old text: 
If a host is multihomed because it is dual-stack, the local preference
SHOULD be set equal to the precedence value for IP addresses described
in RFC 6724 [RFC6724]. If the host operating system provides an API
for discovering preference among different addresses, those
preferences SHOULD be used for the local preference to prioritize
addresses indicated as preferred by the operating system.

New text:
If a host is multihomed because it is dual-stack, the local preference
should be set acording to the current best practice described in
RFC XXXX [ice-dualstack-fairness].

Open Issues:
- No capital SHOULD when referring to a BCP?
- Fairness draft updated to mention RFC6724 so we can avoid referring it
in ICEbis?
- Make ICEbis as simple as possible and let people read the fairness BCP for details? At least avoid having the same information in both RFCs.

Section 4.1.2.2

New text:
One criterion for selection of the type and local preference values is
the use of a media intermediary, such as a TURN server, a tunnel
service such as VPN server, or NAT.  With a media intermediary, if
media is sent to that candidate, it will first transit the media
intermediary before being received.  Relayed candidates are one type
of candidate that involves a media intermediary.  Another are host
candidates obtained from a VPN interface.  When media is transited
through a media intermediary, it can increase the latency between
transmission and reception.  It may or may not increase the packet
losses, because of the additional router hops that may be taken.  It
may increase the cost of providing service, since media will be routed
in and right back out of a media intermediary run by a provider.  If
these concerns are important, the type preference for relayed
candidates SHOULD be lower than host candidates.  The RECOMMENDED
values are 126 for host candidates, 100 for server reflexive
candidates, 110 for peer reflexive candidates, and 0 for relayed
candidates.

Furthermore, if an agent is multihomed and has multiple IP addresses,
the recomandation in RFCXXXX [dual-stack fairnes] should be followed.
If multiple TURN servers are used, local priorities for the candidates
obtained from the TURN servers are chosen in a similar fashion as for
multihomed local candidates: the local preference value is used to
indicate preference among different servers but the preference MUST be
unique for each one.

Another criterion for selection of preferences is IP address family.
ICE works with both IPv4 and IPv6.  It therefore provides a transition
mechanism that allows dual-stack hosts to prefer connectivity over
IPv6, but to fall back to IPv4 in case the v6 networks are
disconnected. Implementation should follow the gudlines from RFCXXX
[dualstack-fairnes] to avoid ecessive dealys in the connectivity check
phase if broken paths exists.

Another criterion for selecting preferences might be security or
privacy.  If a user is a telecommuter, and therefore connected to a
corporate network and a local home network, the user may prefer their
voice traffic to be routed over the VPN or similar tunnel in order to
keep it on the corporate network when communicating within the
enterprise, but use the local network when communicating with users
outside of the enterprise.  In such a case, a VPN address would have a
higher local preference than any other address.

Open Issues:
- Relaxing language that indicates bad bad things happen if a relay is involved.
- Removed Text regarding 6to4. Anyone using it?(NAT64 and DNS64 is the
- way to go?) Can add text to the
  fairness draft to simplify ICEbis. 6to4 is a tunnel and the fairness
  draft talks about tunnels. (None mentioned for the far of calling
  out the bad ones..)
- Added privacy to as a VPN example as well. 
- I feel more text is needed if we want to keep the VPN text there. We
  need to explain split tunneling and how that migh or might not be
  available. Some wording regarding IP adreess leakege would also be
  beneficial.  

.-.
Pål-Erik

> On 10 Jun 2016, at 13:53, [email-masked] wrote:
> 
> 
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2016 12:33:23 +0000

Hi,

The suggested text says that, if a host is multihomed because it is
dual-stack, the guidelines in ice-dualstack-fairness should be followed.

However, section 3 of ice-dualstack-fairness seems to be about multihoming
in general (not necessarily due to dual-stack).

And, as the name of section 3 contains ³Improving², shouldn¹t all
multihoming hosts use ice-dualstack-fairness?

Regards,

Christer

On 10/06/16 15:07, "Ice on behalf of Pal Martinsen (palmarti)"
<[email-masked] on behalf of [email-masked]> wrote:

>- Make ICEbis as simple as possible and let people read the fairness BCP
>for details? At least avoid having the same information in both RFCs.
>
>
>Section 4.1.2.2
>
>New text:

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 10 Jun 2016 13:28:15 +0000

> On 10 Jun 2016, at 14:33, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
So would:

If a host is multihomed because it is dual-stack, the local preference
should be set acording to the current best practice described in
RFC XXXX [ice-dualstack-fairness] section 4.

be better?

ICEBis section 4.1.2.2. talks about multihoming in more generic terms so that can reference without any specific sections.

We can collapse section 3 and 4 in the fairness draft and be more explicit that dual-stack really is a special case of multihoming. But I think people are used to have a distinction between multihoming and dual-stack. 

.-.
Pål-Erik

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2016 14:01:49 +0000

Hi,

My question is: as draft-dsf talks about how to improve multihoming in general, why does 5245bis only references the draft for dual-stack multihoming?

IF you think draft-dsf should be referenced ONLY for dual-stack multihoming, then the draft should ONLY talk about how to improve dual-stack multihoming :)

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Pal Martinsen (palmarti)<mailto:[email-masked]>
Sent: ‎10/‎06/‎2016 16:28
To: Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ice] I-D Action: draft-ietf-ice-dualstack-fairness-03.txt

So would:

be better?

.-.
Pål-Erik

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 10 Jun 2016 18:33:09 +0000

Hmmm,

Now I am confused…

5245bis Section 4.1.2.1 explicitly mention dual-stack as a type of multihoming. In that section it make sense to reference the specific part in dsf that discusses that (Section 4).

Section 4.1.2.2 talks about multihoming in more generic terms, like VPN tunnels, multiple IP addresses pr interface and so on. However it also mentions dual-stack. So in that section it make sense to reference the whole dsf draft.

I think section 4.1.2.2 should have a complete makeover I do not think it really reflects reality.

.-.
Pål-Erik

On 10 Jun 2016, at 16:01, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

> On 10 Jun 2016, at 14:33, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
So would:

be better?

.-.
Pål-Erik

> <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>> Hi all,
>>
>>> On 10 Jun 2016, at 13:53, [email-masked]<mailto:[email-masked]> wrote:
>>>
>>>
>>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Jun 2016 19:13:57 +0000

Hi,

>5245bis Section 4.1.2.1 explicitly mention dual-stack as a type of multihoming. In that section >it make sense to reference the specific part in dsf that discusses that (Section 4).

Yes.

>Section 4.1.2.2 talks about multihoming in more generic terms, like VPN tunnels, multiple IP >addresses pr interface and so on. However it also mentions dual-stack. So in that section it >make sense to reference the whole dsf draft.

Ok, I now see that you have added a reference to the draft in your suggested new text. Sorry for the confusion.

>I think section 4.1.2.2 should have a complete makeover I do not think it really reflects reality.

Feel free to suggest a change :)

Regards,

Christer

Hi,

Regards,

Christer

So would:

be better?

.-.
Pål-Erik

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 17 Jun 2016 12:42:23 +0000

Hi,

On 10 Jun 2016, at 21:13, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Yes.

Pull Request (https://github.com/ice-wg/rfc5245bis/pull/8) tries to address this.

- Adds references to the multihome dualstack draft.
- Changed text so intermediaries like TURN not always have a negative impact  on the media flow. A common scenario is to use TURN to route media though a”transit network” to improve RTT and BW availability.

I still fell we should say more regarding split VPN tunnelling and address leakages. But that may belong in the security section?

.-.
Pål-Erik

Regards,

Christer

Hi,

Regards,

Christer

So would:

be better?

.-.
Pål-Erik

>>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 17 Jun 2016 17:31:27 -0500

Hi,

In your opinion, is this version ready to move to IETF last call? Or do 
you plan other updates.

I note that section 5, paragraph 3 has one remaining upper-case MUST. We 
can deal with that after IETF last call (but don't be surprised if 
people comment on it.)

Thanks!

Ben.

On 10 Jun 2016, at 7:07, Pal Martinsen (palmarti) wrote:

> - Make ICEbis as simple as possible and let people read the fairness 
> BCP for details? At least avoid having the same information in both 
> RFCs.
>
>
> Section 4.1.2.2
>
> New text:

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 20 Jun 2016 13:04:27 +0000

> On 18 Jun 2016, at 00:31, Ben Campbell <[email-masked]> wrote:
> 
> Hi,
> 
No plans for updating the dualstack-fairness draft. Probably some nits remaining in 5245bis to properly reference and clean up surrounding text.

If something significant changes in rfc 5245bis the dualstack fairness draft might need to be updated. 

> can deal with that after IETF last call (but don't be surprised if 
That MUST is part of a quote from rfc5245bis section 4.1.2. (Actually it should be section 4.1.2.1 to be more precise, can submit a new version to fix that, but waiting to see if any more changes are necessary if ICEBis changes.)

So hopefully it is ok to quote text from another RFC containing uppercase MUST without needing to have the standard MUST, SHOULD etc boilerplate? 

.-.
Pål-Erik

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 20 Jun 2016 09:45:16 -0500

On 20 Jun 2016, at 8:04, Pal Martinsen (palmarti) wrote:

> No plans for updating the dualstack-fairness draft. Probably some nits 
> remaining in 5245bis to properly reference and clean up surrounding 
> text.
>

With the normative reference, this won't be published until 5245bis is 
published. We can progress this draft now and let it wait in the RFC 
editors queue, where we could make a last minute change if necessary. Or 
we could hold this draft back in the working group and progress them 
together.

I favor the former. Does anyone think otherwise?

> That MUST is part of a quote from rfc5245bis section 4.1.2. (Actually 
> it should be section 4.1.2.1 to be more precise, can submit a new 
> version to fix that, but waiting to see if any more changes are 
> necessary if ICEBis changes.)
>
> So hopefully it is ok to quote text from another RFC containing 
> uppercase MUST without needing to have the standard MUST, SHOULD etc 
> boilerplate?

Ah, on closer inspection the quote is fine as is.

>>> - Fairness draft updated to mention RFC6724 so we can avoid 
>>> referring
>>> it
>>> in ICEbis?
>>> - Relaxing language that indicates bad bad things happen if a relay 
>>> is
>>> involved.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jun 2016 11:53:43 +0000

Hi,

I agree that we should progress the draft, if the community considers that
it¹s ready. There is a long list of drafts coming up, so let¹s move
forward whatever we can.

I also ask people to take a look at the 5245bis pull request that Pål has
created for this: https://github.com/ice-wg/rfc5245bis/pull/8

I intend to merge it, and submit a new version of draft-5245bis,
relatively soon.

Regards,

Christer

On 20/06/16 17:45, "Ice on behalf of Ben Campbell" <[email-masked]

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 23 Jun 2016 19:49:28 -0500

I requested IETF last call.

Thanks!

Ben.

On 20 Jun 2016, at 9:45, Ben Campbell wrote:

>> No plans for updating the dualstack-fairness draft. Probably some 
>> nits remaining in 5245bis to properly reference and clean up 
>> surrounding text.
>>
> editors queue, where we could make a last minute change if necessary. 
> Or we could hold this draft back in the working group and progress 
> them together.
>