On Tue, 8 Jan 2002, Farid Khafizov wrote:
> As a follow up on IETF-52 meeting discussions, we
> suggest adding the following text to 2.5g/3g ID:
> - a paragraph on VJC
> - a section on Bandwidth Oscillation
some very brief comments below from a quick pass:
> We also think that some info about CDMA2000 should be in the
> document. It could go into the same section where specifics of
> UMTS are being discussed (Section 2), or be part of Bandwidth
> Oscillation section.
>
> Please provide your feedback.
> --Farid
>
> -----------------------------------
> 1. Disabling Van Jacobson TCP/IP Header Compression
>
> Van Jacobson TCP/IP header compression (VJC) algorithm [35] is
> negotiated between peer PPP layers. In CDMA2000 networks it could be
> implemented between the Mobile Terminal Equipment, such as laptop computer,
> and the Packet Data Serving Node. The algorithm was designed to increases
> application layer throughput by reducing packetization overhead. In the
> absence of TCP segment errors, for MTU=1000 Bytes, enabling VJC increases
> throughput by about 4%. However, experiments have shown that in the presence
> of TCP segment errors, VJC is not desirable because it does not allow TCP to
> take advantage of Fast Retransmit Fast Recovery mechanism [n4]. VJC
> algorithm transmits not the TCP/IP headers but only the changes in the
> headers of consecutive segments. Therefore, a segment error causes the
> transmitting and receiving TCP sequence numbers to go out of synch. When a
> TCP segment is lost, none of the following segment will go through until RTO
> expires.
>
> It is recommended to disable VJC algorithm unless TCP segment errors
> are very low.
I can't see the ROHC crowd being comfortable with this; I see
Carsten's got PPP/ROHC in last call.
http://www.normos.org/ietf/draft/draft-ietf-rohc-over-ppp-04.txt
Do similar comments apply to the increasing number of ROHC variants in
that ever-growing ROHC bubble? Some comments on ROHC work (and even
how expanding stateful compression relying on flow ordering beyond a
single link to a network path is just silly due to the failure modes
and expectations imposed on the network, where congestion can be a
fact of life) may well be appropriate.
On bandwidth oscillation (also really including extreme capacity
oscillations? I like the BO=undesirable connotations, though):
> The best approach to avoiding adverse effects of BO, is, perhaps,
> proper wireless sub-network design.
here is a good place to reference Phil's link design draft.
L.
<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:29 EST