< draft-jonsson-3gpp2-rohc-rtp-0-byte-requirements-01.txt		draft-jonsson-3gpp2-rohc-rtp-0-byte-requirements-02.txt >
	Network Working Group Lars-Erik Jonsson, Ericsson (editor)		Network Working Group Lars-Erik Jonsson, Ericsson (editor)
	INTERNET-DRAFT		INTERNET-DRAFT
	Expires: October 2001 Thinh Nguyenphu, Nokia		Expires: November 2001 Thinh Nguyenphu, Nokia
	Raymond Hsu, Qualcomm		Raymond Hsu, Qualcomm
	Wayne Bowen, Motorola		Wayne Bowen, Motorola
	Rajesh Bhalla, Cisco		Rajesh Bhalla, Cisco
	Mark Lipford, Sprint		Mark Lipford, Sprint
	Tom Hiller, Lucent		Tom Hiller, Lucent
	April 18, 2001		May 1, 2001
	3GPP2 Requirements for 0-byte ROHC IP/UDP/RTP Header Compression		3GPP2 Requirements for 0-byte ROHC IP/UDP/RTP Header Compression
	<draft-jonsson-3gpp2-rohc-rtp-0-byte-requirements-01.txt>		<draft-jonsson-3gpp2-rohc-rtp-0-byte-requirements-02.txt>
	Status of this memo		Status of this memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	March 29, 2001 - 00		March 29, 2001 - 00
	First official draft. Modified abstract and introduction clearly		First official draft. Modified abstract and introduction clearly
	stating that this is a 3GPP2 input to the work to be done in ROHC.		stating that this is a 3GPP2 input to the work to be done in ROHC.
	A fifth section of chapter 2 has been added addressing 3GPP2		A fifth section of chapter 2 has been added addressing 3GPP2
	specific concerns.		specific concerns.
	April 18, 2001 û 01		April 18, 2001 û 01
	Updated version with minor corrections and modifications to		Updated version with minor corrections and modifications to
	various parts of the draft. This release is expected to be the		various parts of the draft.
	final version of this input document from the 3GPP2 community.
			May 1, 2001 - 02
			Wording in section 2.3:3 changed to be consistent with [RTR-REQ].
			This release is expected to be the final version of this input
			document from the 3GPP2 community.
	1. Introduction		1. Introduction
	The goal of the ROHC WG is to develop header compression schemes that		The goal of the ROHC WG is to develop header compression schemes that
	perform well over links with high error rates and long link roundtrip		perform well over links with high error rates and long link roundtrip
	times. The schemes must perform well for cellular links, using		times. The schemes must perform well for cellular links, using
	technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes		technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes
	should also be applicable to other future link technologies with high		should also be applicable to other future link technologies with high
	loss and long roundtrip times.		loss and long roundtrip times.
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	not lost or damaged.		not lost or damaged.
	Justification: Error propagation reduces spectral efficiency and		Justification: Error propagation reduces spectral efficiency and
	reduces quality.		reduces quality.
	Note: There are at least two kinds of error propagation; loss		Note: There are at least two kinds of error propagation; loss
	propagation, where an error causes subsequent headers to be lost,		propagation, where an error causes subsequent headers to be lost,
	and damage propagation, where an error causes subsequent headers		and damage propagation, where an error causes subsequent headers
	to be damaged.		to be damaged.
	3a. Moderate Packet Reordering(*): The scheme should efficiently		3a. Moderate Packet Misordering(*): The scheme should efficiently
	handle moderate reordering (2-3 packets) in the packet stream		handle moderate misordering (2-3 packets) in the packet stream
	reaching the compressor.		reaching the compressor.
	Justification: This kind of reordering is common.		Justification: This kind of reordering is common.
	3b. Packet Reordering(*): The scheme should be able to compress when		3b. Packet Misordering(*): The scheme should be able to compress when
	there are reordered packets in the RTP stream reaching the		there are misordered packets in the RTP stream reaching the
	compressor.		compressor. No misordering is expected on the link between
			compressor and decompressor
	Justification: Reordering happens regularly in the Internet.		Justification: Misordering happens regularly in the Internet.
	However, since the Internet is engineered to run TCP reasonably		However, since the Internet is engineered to run TCP reasonably
	well, excessive reordering will not be common and need not be		well, excessive misordering will not be common and need not be
	handled with optimum efficiency.		handled with optimum efficiency.
	4. Processing delay(*): The scheme must not contribute significantly		4. Processing delay(*): The scheme must not contribute significantly
	to system delay budget.		to system delay budget.
	5. Algorithm delay: The scheme should not noticeably add to the end-		5. Algorithm delay: The scheme should not noticeably add to the end-
	to-end delay.		to-end delay.
	Justification: RTP packets carrying data for interactive voice or		Justification: RTP packets carrying data for interactive voice or
	video have a limited end-to-end delay budget.		video have a limited end-to-end delay budget.
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	Sprint PCS Fax: +1 (913) 890 4100		Sprint PCS Fax: +1 (913) 890 4100
	15405 College Blvd.		15405 College Blvd.
	Lenexa, KS 66219 E-mail: mlipfo01@sprintspectrum.com		Lenexa, KS 66219 E-mail: mlipfo01@sprintspectrum.com
	Tom Hiller Tel: +1 (630) 979 7673		Tom Hiller Tel: +1 (630) 979 7673
	Lucent Technologies Fax: +1 (630) 979 7673		Lucent Technologies Fax: +1 (630) 979 7673
	263 Shuman Dr.		263 Shuman Dr.
	Naperville, IL 60566		Naperville, IL 60566
	USA E-mail: tom.hiller@lucent.com		USA E-mail: tom.hiller@lucent.com
	This Internet-Draft expires October 18, 2001.		This Internet-Draft expires November 1, 2001.
End of changes. 10 change blocks.
	12 lines changed or deleted		19 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/