Subject: Asymmetries [Was: RE:PILC Minutes]

From: [email-masked]
Date: Tue, 23 Nov 1999 08:44:47 +0100

Just to give my two cents in the asymmetry debate,

What if we introduce bit-errors over a wireless channel?
this will stop delayed acking, leaving a 1500:1 asymmetry factor.

If SACK is used to handle the biterrors the compression
will be less effective, which lowers the sustainable asymmetry factor
further.

In the project I am working in we have a downward bandwidth of 11 Mbps
and a reverse bandwidth of 9.6 kbps. To handle the bit-errors we have
implemented an extension of the Ack-filter that handles SACK. This
works good even if we loose Ack's on the return path. Our sender has
been changed to count bytes Ack'ed not segments so we don't get the
penalty of a slow cwnd growth. Without these extensions we can not 
handle the asymmetry, eventhough it is less than 3000:1.

/Jonas Haggård Ljungquist

>> Van Jacobson: RFC 1144 header compression, in one-byte mode (as opposed
to
>> five-six-byte mode), handles 3000:1 asymmetry. Are we seeing connection
>> paths that are more asymmetric than this? What's the point?
>
>Again, as I clarified when Van asked this question, our view of
>asymmetry (at least as far as the I-D is concerned) is not limited to 
>bandwidth asymmetry. There are instances of asymmetry in the MAC 
>protocol (often due to the fundamental distributed setting of the network 
>rather than poor engineering choices). In such situations, performance
>would benefit a lot more from *infrequent* acks than from *smaller* 
>(i.e., header compressed) acks, even if the bandwidth used by the ack 
>stream is the same in both cases.
>
>-Venkat

---

From: Haider Shakargi <[email-masked]>
Date: Wed, 24 Nov 1999 13:07:21 +0100

I agree that SACK is essential in LFN networks to handle
bit-errors on the forward path, and it is rercommended by TCPSAT. A
combination of SACK and byte counting still does not solve the problem of
sender burstiness because of ack losses on the reverse path. This bursty
behaviour of the sender may cause congestion in a router on the forward
path. By using Ack Compression and Decompression method mentioned in Venkata
N. Padmanabhan's presentation in the 46:th IETF meeting [Joh99], you may
compress the SACK and the timestamp options with good compression
effeciency. 

-------------------------------------------------------------------------
Haider Shakargi                                   | Tele: +46 31 7036638
Link and Network Design section (NJ) | Fax: +46 31 7036033
Ericsson Mobile Data Design AB
S:t Sigfridsg-89
SE-412 66 Gothenburg, Sweden

> -----Original Message-----
> From:	[email-masked]
> [SMTP:[email-masked]]
> Sent:	den 23 november 1999 08:45
> To:	[email-masked]
> Subject:	Asymmetries [Was: RE:PILC Minutes]
> 
>