draft-ietf-rmcat-wireless-tests-03.txt		draft-ietf-rmcat-wireless-tests-04.txt
	Network Working Group Z. Sarker		Network Working Group Z. Sarker
	Internet-Draft I. Johansson		Internet-Draft I. Johansson
	Intended status: Informational Ericsson AB		Intended status: Informational Ericsson AB
	Expires: May 18, 2017 X. Zhu		Expires: November 17, 2017 X. Zhu
	J. Fu		J. Fu
	W. Tan		W. Tan
	M. Ramalho		M. Ramalho
	Cisco Systems		Cisco Systems
	November 14, 2016		May 16, 2017
	Evaluation Test Cases for Interactive Real-Time Media over Wireless		Evaluation Test Cases for Interactive Real-Time Media over Wireless
	Networks		Networks
	draft-ietf-rmcat-wireless-tests-03		draft-ietf-rmcat-wireless-tests-04
	Abstract		Abstract
	There is an ongoing effort in IETF RMCAT working group to standardize		There is an ongoing effort in IETF RMCAT working group to standardize
	rate adaptation algorithm(s) for real-time interactive communication.		rate adaptation algorithm(s) for real-time interactive communication.
	To ensure seamless and robust user experience, the proposed rate		To ensure seamless and robust user experience, the proposed rate
	adaptation algorithm(s) should work well across all access network		adaptation algorithm(s) should work well across all access network
	types. This document describes test cases for evaluating		types. This document describes test cases for evaluating
	performances of the proposed rate adaptation solutions over LTE and		performances of the proposed rate adaptation solutions over LTE and
	Wi-Fi networks.		Wi-Fi networks.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 May 18, 2017.		This Internet-Draft will expire on November 17, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	4.1. Bottleneck in Wired Network . . . . . . . . . . . . . . . 12		4.1. Bottleneck in Wired Network . . . . . . . . . . . . . . . 12
	4.1.1. Network topology . . . . . . . . . . . . . . . . . . 12		4.1.1. Network topology . . . . . . . . . . . . . . . . . . 12
	4.1.2. Test setup . . . . . . . . . . . . . . . . . . . . . 13		4.1.2. Test setup . . . . . . . . . . . . . . . . . . . . . 13
	4.1.3. Typical test scenarios . . . . . . . . . . . . . . . 14		4.1.3. Typical test scenarios . . . . . . . . . . . . . . . 14
	4.1.4. Expected behavior . . . . . . . . . . . . . . . . . . 14		4.1.4. Expected behavior . . . . . . . . . . . . . . . . . . 14
	4.2. Bottleneck in Wi-Fi Network . . . . . . . . . . . . . . . 15		4.2. Bottleneck in Wi-Fi Network . . . . . . . . . . . . . . . 15
	4.2.1. Network topology . . . . . . . . . . . . . . . . . . 15		4.2.1. Network topology . . . . . . . . . . . . . . . . . . 15
	4.2.2. Test setup . . . . . . . . . . . . . . . . . . . . . 15		4.2.2. Test setup . . . . . . . . . . . . . . . . . . . . . 15
	4.2.3. Typical test scenarios . . . . . . . . . . . . . . . 16		4.2.3. Typical test scenarios . . . . . . . . . . . . . . . 16
	4.2.4. Expected behavior . . . . . . . . . . . . . . . . . . 17		4.2.4. Expected behavior . . . . . . . . . . . . . . . . . . 17
	4.3. Potential Potential Test Cases . . . . . . . . . . . . . 18		4.3. Other Potential Test Cases . . . . . . . . . . . . . . . 18
	4.3.1. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . 18		4.3.1. EDCA/WMM usage . . . . . . . . . . . . . . . . . . . 18
	4.3.2. Legacy 802.11b Effects . . . . . . . . . . . . . . . 18		4.3.2. Effects of Legacy 802.11b Devices . . . . . . . . . . 18
	5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18		5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	skipping to change at page 14, line 19 ¶		skipping to change at page 14, line 19 ¶
	+ Traffic timeline: See Section 4.1.3		+ Traffic timeline: See Section 4.1.3
	4.1.3. Typical test scenarios		4.1.3. Typical test scenarios
	o Single uplink RMCAT flow: N=1 with uplink direction and M=0.		o Single uplink RMCAT flow: N=1 with uplink direction and M=0.
	o One pair of bi-directional RMCAT flows: N=2 (with one uplink flow		o One pair of bi-directional RMCAT flows: N=2 (with one uplink flow
	and one downlink flow); M=0.		and one downlink flow); M=0.
	o One pair of bi-directional RMCAT flows, one on-off CBR over UDP		o One pair of bi-directional RMCAT flows, one on-off CBR over UDP
	flow on uplink : N=2 (with one uplink flow and one downlink flow);		flow on uplink: N=2 (with one uplink flow and one downlink flow);
	M=1 (uplink). CBR flow on time at 0s-60s, off time at 60s-119s		M=1 (uplink). CBR flow on time at 0s-60s, off time at 60s-119s.
	o One pair of bi-directional RMCAT flows, one off-on CBR over UDP		o One pair of bi-directional RMCAT flows, one off-on CBR over UDP
	flow on uplink : N=2 (with one uplink flow and one downlink flow);		flow on uplink: N=2 (with one uplink flow and one downlink flow);
	M=1 (uplink). UDP off time: 0s-60s, on time: 60s-119s		M=1 (uplink). UDP off time: 0s-60s, on time: 60s-119s.
	o One RMCAT flow competing against one long-live TCP flow over		o One RMCAT flow competing against one long-live TCP flow over
	uplink: N=1 (uplink) and M = 1(uplink), TCP start time: 0s, end		uplink: N=1 (uplink) and M = 1(uplink), TCP start time at 0s and
	time: 119s.		end time at 119s.
	4.1.4. Expected behavior		4.1.4. Expected behavior
	o Single uplink RMCAT flow: the candidate algorithm is expected to		o Single uplink RMCAT flow: the candidate algorithm is expected to
	detect the path capacity constraint, to converge to bottleneck		detect the path capacity constraint, to converge to bottleneck
	link capacity and to adapt the flow to avoid unwanted oscillation		link capacity and to adapt the flow to avoid unwanted oscillation
	when the sending bit rate is approaching the bottleneck link		when the sending bit rate is approaching the bottleneck link
	capacity. No excessive rate oscillations should be present.		capacity. No excessive rate oscillations should be present.
	o Bi-directional RMCAT flows: It is expected that the candidate		o Bi-directional RMCAT flows: It is expected that the candidate
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 17 ¶
	timely fashion to the resulting changes in available bandwidth.		timely fashion to the resulting changes in available bandwidth.
	o Multiple bi-directional RMCAT flows with TCP traffic: overall		o Multiple bi-directional RMCAT flows with TCP traffic: overall
	bandwidth usage shared by all RMCAT flows should not be		bandwidth usage shared by all RMCAT flows should not be
	significantly lower than those achieved by the same number of bi-		significantly lower than those achieved by the same number of bi-
	directional TCP flows. In other words, the performance of		directional TCP flows. In other words, the performance of
	multiple concurrent TCP flows will be used as a performance		multiple concurrent TCP flows will be used as a performance
	benchmark for this test scenario. All downlink RMCAT flows are		benchmark for this test scenario. All downlink RMCAT flows are
	expected to obtain similar bandwidth with respect to each other.		expected to obtain similar bandwidth with respect to each other.
	4.3. Potential Potential Test Cases		4.3. Other Potential Test Cases
	4.3.1. EDCA/WMM usage		4.3.1. EDCA/WMM usage
	EDCA/WMM is prioritized QoS with four traffic classes (or Access		EDCA/WMM is prioritized QoS with four traffic classes (or Access
	Categories) with differing priorities. RMCAT flows should achieve		Categories) with differing priorities. RMCAT flows should achieve
	better performance (i.e., lower delay, fewer packet losses) with		better performance (i.e., lower delay, fewer packet losses) with
	EDCA/WMM enabled when competing against non-interactive background		EDCA/WMM enabled when competing against non-interactive background
	traffic (e.g., file transfers). When most of the traffic over Wi-Fi		traffic (e.g., file transfers). When most of the traffic over Wi-Fi
	is dominated by media, however, turning on WMM may actually degrade		is dominated by media, however, turning on WMM may actually degrade
	performance since all media flows now attempt to access the wireless		performance since all media flows now attempt to access the wireless
	transmission medium more aggressively, thereby causing more frequent		transmission medium more aggressively, thereby causing more frequent
	collisions and collision-induced losses. This is a topic worthy of		collisions and collision-induced losses. This is a topic worthy of
	further investigation.		further investigation.
	4.3.2. Legacy 802.11b Effects		4.3.2. Effects of Legacy 802.11b Devices
	When there is 802.11b devices connected to modern 802.11 network, it		When there is 802.11b devices connected to modern 802.11 network, it
	may affect the performance of the whole network. Additional test		may affect the performance of the whole network. Additional test
	cases can be added to evaluate the affects of legancy devices on the		cases can be added to evaluate the affects of legancy devices on the
	performance of RMCAT congestion control algorithm.		performance of RMCAT congestion control algorithm.
	5. Conclusion		5. Conclusion
	This document defines a collection of test cases that are considered		This document defines a collection of test cases that are considered
	important for cellular and Wi-Fi networks. Moreover, this document		important for cellular and Wi-Fi networks. Moreover, this document
	skipping to change at page 20, line 20 ¶		skipping to change at page 20, line 20 ¶
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-rmcat-cc-requirements]		[I-D.ietf-rmcat-cc-requirements]
	Jesup, R. and Z. Sarker, "Congestion Control Requirements		Jesup, R. and Z. Sarker, "Congestion Control Requirements
	for Interactive Real-Time Media", draft-ietf-rmcat-cc-		for Interactive Real-Time Media", draft-ietf-rmcat-cc-
	requirements-09 (work in progress), December 2014.		requirements-09 (work in progress), December 2014.
	[I-D.ietf-rmcat-eval-test]		[I-D.ietf-rmcat-eval-test]
	Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test		Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
	Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-		Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
	eval-test-04 (work in progress), October 2016.		eval-test-05 (work in progress), April 2017.
	[IEEE802.11]		[IEEE802.11]
	"Standard for Information technology--Telecommunications		"Standard for Information technology--Telecommunications
	and information exchange between systems Local and		and information exchange between systems Local and
	metropolitan area networks--Specific requirements Part 11:		metropolitan area networks--Specific requirements Part 11:
	Wireless LAN Medium Access Control (MAC) and Physical		Wireless LAN Medium Access Control (MAC) and Physical
	Layer (PHY) Specifications", 2012.		Layer (PHY) Specifications", 2012.
	[LTE-simulator]		[LTE-simulator]
	"NS-3, A discrete-Event Network Simulator",		"NS-3, A discrete-Event Network Simulator",
	skipping to change at page 21, line 38 ¶		skipping to change at page 21, line 38 ¶
	Wei-Tian Tan		Wei-Tian Tan
	Cisco Systems		Cisco Systems
	725 Alder Drive		725 Alder Drive
	Milpitas, CA 95035		Milpitas, CA 95035
	USA		USA
	Email: dtan2@cisco.com		Email: dtan2@cisco.com
	Michael A. Ramalho		Michael A. Ramalho
	Cisco Systems		Cisco Systems, Inc.
	8000 Hawkins Road		8000 Hawkins Road
	Sarasota, FL 34241		Sarasota, FL 34241
	USA		USA
	Phone: +1 919 476 2038		Phone: +1 919 476 2038
	Email: mramalho@cisco.com		Email: mramalho@cisco.com
End of changes. 14 change blocks.
	17 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/