Subject: pilc minutes (corrected)

From: Aaron Falk <[email-masked]>
Date: Mon, 14 Jan 2002 11:03:49 -0800

All-

Please substitute the following modified version of the wg minutes.  I have
corrected name spelling for Khafizov.

--aaron

======================================================
Performance Implications of Link Characteristics WG (pilc)

The PILC working group meeting was held on Tuesday, December 11 at
1300-1400.  The meeting was chaired by Aaron Falk and the following
agenda was followed completely.

AGENDA:
Agenda Bashing                          chairs          2min
Working Group Status                    chairs          3min
CDMA2000 issues                         F. Khafizov    10min
  draft-khafizov-pilc-cdma2000-00.txt
  Q: integrate into 2.5g3g or new doc?
2.5g/3g Update                          H. Inamura      10min
  draft-ietf-pilc-2.5g3g-05.txt
  Q: ready for wg last call?
LINK last call comments                 P. Karn         10min
  draft-ietf-pilc-link-design-08.txt    M. Allman
PILC-related issues in ROHC             C. Borman       10min
IP-DVB announcement                     G. Fairhurst    2min
Adjourn

The meeting started promptly at 13:00 and Blue Sheets were circulated.

Aaron Falk went over the Working Group Status ARQ is in IESG
review. ASYM is going to IESG any day.  LINK design is in last call.
Mark Allman will be taking over editing for Phil Karn's 2.5/3G document
is near last call but needs to incorporate CDMA2000 information.

=========================

CDMA2000

F. Khafizov presented slides on TCP performance over CDMA 2000
networks.  Issues to be addressed include bandwidth oscillation, high
BER, and bandwidth asymmetry.  Bandwidth oscillation degrades
throughput through spurious timeouts.  True of any system with widely
varying bandwidth. 

* Bandwidth Oscillations (BO)
  -	Significant throughput degradation
  -	Not cdma2000 specific
  -	Related to resource contention
  -	Fixes include 1) fix TCP, 2) Fix network or 3) leave as is.
  -	Possible fixes
   o	 Adjust RTO value
   o	 enable Time Stamp option
   o	 increase window size
   o	 minimize ACK delay
  -	Other recommendations
   o	 Aggressive link level error recovery
   o	 disable VJ header compression
   o	 use SACK
  -	Options
   o	 Incorporate  BO in 2.5g/3g and/or LINK ID
   o	 make a separate ID for BO
   o	 have a section in 2.5G/#g ID addressing specifics of CMDA2000

Suggestions from chair and floor moved toward including in existing
documents rather than stand-alone document.

F. Khafizov   volunteer to generate text for the documents.

============

Hiroshi Inamura      presented slides on  2.5G/3G
* Reviewed open issues
  -	header compressions
  -	active queue mgt.
  -	Others
* RTO typically 2s is to small?
  -	Yes
* New Sections
  -	 VJ header compression not recommended

Comments from the floor:

ECN section needs expansion as ECN may be quite beneficial.  Question
as to whether or not the effects of cell changes being incorporated
into draft.

=============

Phil Karn commented that the LINK document appears to be very near
completion.  Bandwidth on Demand and bandwidth oscillations may need
some additional attention.

Floor Comments:
Asymmetry may need a bit of revision as it was written early on.

============

Carsten Bormann presented slides on issues in Robust Header
Compression related to PILC

The following is a summary of Carsten's slides:

Robust Header Compression (ROHC)
  -	Header Compression  is prerequisite for all IP wireless
  -	Wireless = lossy, long latency

Work items

Robust Header Compression  of IP/UDP/RTP
  -	need for e2e VoIP/video
  -	RFC3095 july 2001 used by 3GPP and 3GPP2
  -	ROHC over PPP; 0-byte LLA submitted to IESG

ROHC for TCP  is starting to gel

New: signaling compression (reduce latency)
  -	universal decompressor

ROHC is working on MIBs
     Next work will probably be related to  SCTP

RFC 2507 is not good enough as it does not handle options like SACK,
timestamps
  -	need to compress ECN bits well
  -	cope with TCP's extensibility
  -	(state of the ar ha advanced)

Requirements drafts presented:  2 drafts
  -	please read and comment on 01/03 versions once available!

Solutions :  two drafts in the process of merging 
	     Need wider input wrt next generation TCP

ROHC TCP Requirements
  -	Links with few residual erros but may have packet loss
  -	Robustness
   o	 Should not disable TCOP mechanisms
   o	 Must NOT generate damaged headers
   o	 Must deal with current and future TCPs
   o	 TCP sequence numbers and IP ID less predictable

TCP Sample Issues
  -	TCP checksum and.or additional CRC for checking
  -	Unidirectional vs bi-directional compression
  -	Can ROHC ignore IP options?
  -	Compress in tunnel encapsulations, too?
   o	 Reordering (prohibited, detected, allowed)?
  -	Integrate with ASYM mechanisms
  -	What are the assumptions about ECN behavior?
  -	What loss amplifications behaviours are actually acceptable?
  -	IPR

Comments from floor

  - even if residual error is low, what is error distribution (burst
    errors vs uniform distribution errors).  However, residual bit
    errors as defined by ROHC are packet with errors passed from layer
    2 too layer 3.

===================

IP-DVB announcement                     G. Fairhurst    2min

G. Fairhurst extended an invitation to an informal meeting on 12/12 at
15:30 - 17:30.  The meeting will be on IP over DVB.  It is not an BoF,
but a maillist will be created for those interested in this subject.
More information can be found at
http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/.

---

From: "Farid Khafizov"<[email-masked]>
Date: Thu, 17 Jan 2002 17:17:57 -0600

Enclosed please find suggested text on Bandwidth Oscillation for LINK-ID
and comments on the latest version of the draft.
--Farid

//-------------------------------------------------------------------------
// Suggested addition to LINK-ID (draft-ietf-pilc-link-design-08.txt)
// To follow directly "BoD Subnets" section
//-------------------------------------------------------------------------

Bandwidth Oscillation

When shared resources are periodically assigned to users for a limited time,
BoD systems may experience Bandwidth Oscillation. One example is a CDMA
based wireless data network such as UMTS or CDMA2000. Limited pool of
orthogonal codes and RF transmit power necessitates time-sharing of those
resources. If a number of users require, for example, large data files
transfer at the same time, the system (e.g., the scheduler) may have to
repeatedly allocate and de-allocate resources for each user. Such mode of
operation causes Bandwidth Oscillation, which can result in spurious
timeouts, and, hence, throughput degradation. Although effects of spurious
retransmission have been extensively studied in the literature (e.g.,
[LK00]), it is important to note that in some cases Bandwidth Oscillation
can be the single most important factor in throughput reduction. It has been
shown that for some configurations of CDMA2000 networks, throughput
degradation can be in excess of 50% [n1]. Experiments have also shown that
effects of Bandwidth Oscillation can amplify throughput degradation caused
by TCP segment loss or reordering. 

At the time of writing of this document IETF was working on recommendations
for TCP options [n2] that could reduce adverse effects of BOS. Consensus of
this forum, however, is that a better solution can be found by properly
designing sub-networks. For a fixed TCP configuration, throughput reduction
depends on the high bandwidth (HB), the duration of HB (B), the low
bandwidth (LB) and the duration of LB (D). By choosing appropriate
combination of <HB,B,LB,D> throughput degradation can be reduced or even
avoided. However, in cases when multiple users share same resources, B and D
are related and reducing D becomes impossible without reduction of B. In
addition, attempts to reduce B and/or D may increase signaling overhead,
and, therefore, limit designers' flexibility in choosing the optimal
configuration.

[n1] F.Khafizov, M.Yavuz, "Running TCP over IS-2000", to appear in Proc. of
IEEE ICC 2002
[n2] H. Inamura, G. Montenegro, M. Hata, M. Hara, J. James, W. Gilliam, A.
Hameed, R. Ludwig, R. Garces, P. Ford, F. Wills, "TCP over 2.5G and 3G
Wireless Networks", work in progress as internet-draft,
draft-ietf-pilc-2.5g3g-05, November 2001

//-------------------------------------------------------------------------
// Comments on existing text available at
http://people.qualcomm.com/karn/pilc.txt
//-------------------------------------------------------------------------
Section: Choosing the MTU in Slow Networks

>		 	    "However, the link resources used to
>   send the aborted packet are lost, and overall throughput will
>   decrease."

It is probably me not being a native speaker, but I felt the above 
sentence wasn't very clear: I had trouble with present and future tense 
verbs in one sentence. Perhaps it should be written as

		 	    "However, when the link resources used to
   send the aborted packet are lost, the overall throughput 
   decreases."

or 
		 	    "However, in this case, the link resources used
to
   send the aborted packet are lost, and overall throughput 
   decreases."

//-------------------------------------------------------------------------
Section: How TCP Works

>   "Since the most common cause of packet loss is congestion"

Although this is true considering overall Internet traffic, 
in (at least some) wireless networks this assumption is not true. 
Experiments suggest that packet loss due to
high BER is comparable or higher than that due to congestion.
Perhaps that fact should be mentioned with the reference to rfc3155.

//-------------------------------------------------------------------------
Section: How TCP Works

>		"Recent proposals have been made to lower the
>		   dupack threshold to 2."

Would be nice to have a reference to "proposals"

//-------------------------------------------------------------------------
Section: TCP Performance Characteristics -> Analysis of Link-Layer Effects
on TCP Performance

>	"If this link layer were used in the Internet, on a path that
>	   otherwise had a round trip of of 80 msec, "

"of of"

//-------------------------------------------------------------------------
Section: Bandwidth Asymmetries

>	"acknowledgments is too large, the slow return of of the ACKs
directly"

"of of"

//-------------------------------------------------------------------------
Section: Buffering, flow & congestion control

>	"Available Bit rate (ABR" 

should have "Rate"

//-------------------------------------------------------------------------
Section: Compression

>	"We make a stronger recommendation that subnetworks operating at low
>	   speed or with small MTUs compress IP and transport-level headers"

should be

	"We make a stronger recommendation that subnetworks operating at low
BER conditions and low
	   speed or with small MTUs compress IP and transport-level headers
"

It is mentioned later in the text that in the presence of errors header
compression
is not a good idea. Here one might add that in such circumstances there is
no benefit
of Fast Retransmit/Fast Recovery mechanism.

//-------------------------------------------------------------------------
Section: Mobility

>   "the most appropriate and efficient. Mobility is already an feature of"

article change "an" -> "a"

//-------------------------------------------------------------------------
Section: Security Considerations

>   	"2. Use of 'security by obscurity' [Schneier4] [Crypto9912].  One"
and
>	"3. Inclusion of trapdoors [Schneier4] [Crypto9912].  Trapdoors are"

Reference [Schneier4] is not defined 
//-------------------------------------------------------------------------

> -----Original Message-----
> From:	Aaron Falk [SMTP:[email-masked]]
> Sent:	Monday, January 14, 2002 1:04 PM
> To:	pilc; [email-masked]
> Subject:	pilc minutes (corrected)