< draft-ietf-mif-happy-eyeballs-extension-08.txt		draft-ietf-mif-happy-eyeballs-extension-09.txt >
	Internet Engineering Task Force G. Chen		Internet Engineering Task Force G. Chen
	Internet-Draft China Mobile		Internet-Draft China Mobile
	Intended status: Informational C. Williams		Intended status: Informational C. Williams
	Expires: June 22, 2016 Consultant		Expires: August 24, 2016 Consultant
	D. Wing		D. Wing
	A. Yourtchenko		A. Yourtchenko
	Cisco Systems, Inc.		Cisco Systems, Inc.
	December 20, 2015		February 21, 2016
	Happy Eyeballs Extension for Multiple Interfaces		Happy Eyeballs Extension for Multiple Interfaces
	draft-ietf-mif-happy-eyeballs-extension-08		draft-ietf-mif-happy-eyeballs-extension-09
	Abstract		Abstract
	This memo proposes extensions to the Happy Eyeball(HE) defined in		This memo proposes extensions to the Happy Eyeball(HE) defined in
	RFC6555 and fit into a multiple provisioning domain architecture.		RFC6555 and fit into a multiple provisioning domain architecture.
	Happy Eyeballs in MIF would make the selection process smoother by		Happy Eyeballs in MIF would make the selection process smoother by
	using connectivity tests over pre-filtered interfaces according to		using connectivity tests over pre-filtered interfaces according to
	defined policy. This would choose the most fast interface with an		defined policy. This would choose the most fast interface with an
	automatic fallback mechnism.		automatic fallback mechnism.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 22, 2016.		This Internet-Draft will expire on August 24, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 7, line 52 ¶		skipping to change at page 7, line 52 ¶
	experience. Aggressive timeouts may achieve quick interface		experience. Aggressive timeouts may achieve quick interface
	handover, but at the cost of traffic that may be chargeable on		handover, but at the cost of traffic that may be chargeable on
	certain networks, e.g. the handover from WiFi to 3GPP networks brings		certain networks, e.g. the handover from WiFi to 3GPP networks brings
	a charge to customers. Considering the reasons, it is recommended to		a charge to customers. Considering the reasons, it is recommended to
	prioritize the input from users (e.g., real customers or		prioritize the input from users (e.g., real customers or
	applications) through user interface. For default-setting on a		applications) through user interface. For default-setting on a
	system, a hard error [RFC1122] in replied ICMP could serve as a		system, a hard error [RFC1122] in replied ICMP could serve as a
	trigger for the fallback process. When the ICMP soft error is		trigger for the fallback process. When the ICMP soft error is
	present or non-response was received, it's recommended that the		present or non-response was received, it's recommended that the
	timeout should be large enough to allow connection retransmission.		timeout should be large enough to allow connection retransmission.
	[RFC1122] states that such timer MUST be at least 3 minutes to		[RFC1122] states that such timer must be at least 3 minutes to
	provide TCP retransmission. However, several minutes delay may not		provide TCP retransmission. However, several minutes delay may not
	inappropriate for user experiences. A widespread practice [RFC5461]		inappropriate for user experiences. A widespread practice [RFC5461]
	sets 75 seconds to optimize connection process.		sets 75 seconds to optimize connection process.
	More optimal timer may be expected. The particular setting will be		More optimal timer may be expected. The particular setting will be
	very specific to implementations and cases. The memo didn't try to		very specific to implementations and cases. The memo didn't try to
	provide a concrete value because of following concerns.		provide a concrete value because of following concerns.
	o RTT (Round-Trip Time) on different interfaces may vary quite a		o RTT (Round-Trip Time) on different interfaces may vary quite a
	lot. A particular value of timeout may not accurately help to		lot. A particular value of timeout may not accurately help to
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 33 ¶
	example, a interface could be evaluated in the principle of		example, a interface could be evaluated in the principle of
	bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy		bandwidth-delay, termed "Bandwidth-Delay-Product ". Happy
	Eyeballs measures only connection speed. That is, how quickly a		Eyeballs measures only connection speed. That is, how quickly a
	TCP connection is established . It does not measure bandwidth. If		TCP connection is established . It does not measure bandwidth. If
	the fallback has to take various factors into account and make		the fallback has to take various factors into account and make
	balanced decision, it's better to resort to a specific context and		balanced decision, it's better to resort to a specific context and
	implementation.		implementation.
	7.3. DNS Selections		7.3. DNS Selections
	In the Sort process, HE-MIF prioritizes PVD-ID match or		In the Sort process, HE-MIF prioritizes PVD-ID match or [RFC6731]
	[RFC6731]inputs to select a proper server. It could help to address		inputs to select a proper server. It could help to address following
	following two cases.		two cases.
	o A DNS answer may be only valid on a specific provisioning domain,		o A DNS answer may be only valid on a specific provisioning domain,
	but DNS resolver may not be aware of that because DNS reply is not		but DNS resolver may not be aware of that because DNS reply is not
	kept with the provisioning from which the answer comes. The		kept with the provisioning from which the answer comes. The
	situation may become worse if asking internal name with public		situation may become worse if asking internal name with public
	address response or asking public name with private address		address response or asking public name with private address
	answers.		answers.
	o Some FQDNs can be resolvable only by sending queries to the right		o Some FQDNs can be resolvable only by sending queries to the right
	server (e.g., intranet services). Otherwise, a response with		server (e.g., intranet services). Otherwise, a response with
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	[I-D.deng-mif-api-session-continuity-guide] describes session		[I-D.deng-mif-api-session-continuity-guide] describes session
	continuity guidance for application developers. The flow continuity		continuity guidance for application developers. The flow continuity
	topic is beyond this document scope.		topic is beyond this document scope.
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Security Considerations		9. Security Considerations
	The security consideration is following the statement in [RFC6555]and		The security consideration is following the statement in [RFC6555]
	[RFC6418].		and [RFC6418].
	10. Acknowledgements		10. Acknowledgements
	The authors would like to thank Margaret Wasserman, Hui Deng, Erik		The authors would like to thank Margaret Wasserman, Hui Deng, Erik
	Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon		Kline, Stuart Cheshire, Teemu Savolainen, Jonne Soininen, Simon
	Perreault, Zhen Cao, Dmitry Anipko, Ted Lemon, Daniel Migault, Russ		Perreault, Zhen Cao, Dmitry Anipko, Ted Lemon, Daniel Migault, Russ
	White and Bing Liu for their helpful comments.		White and Bing Liu for their helpful comments.
	11. References		11. References
End of changes. 8 change blocks.
	11 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/