Subject: [TIME-LIST] RE: draft-ietf-pilc-asym-00.txt

From: Goran Johansson <[email-masked]>
Date: Fri, 15 Oct 1999 12:24:58 +0200

Aaron Falk wrote:

>Hi, Goran. I have some questions...
>
>> We are working on an idea to remedy the effects of bandwidth
asymmetry
>> using a version of TCP/IP header compression. Our algorithm should be

>> able to achieve effective ACK-sizes considerably smaller than
>> one octet
>> and thus remove the effective bandwidth asymmetry in most realistic
>> systems.
>
>Smaller ACKs would exacerbate traffic symmetry. Perhaps you are
referring to
>the limitations that asymmetric links would pose on performance?

Yes.

>>
>> We implement a compressor at the queue where ACKs get congested
>> and a decompressor somewhere on the other side of the bottleneck
link.
>
>Hmmm...how do you know where the ACKs are getting congested? Congestion

>moves around. Are you assuming that you have a *very* asymmetric tail
>circuit? If so, this sounds like a single link optimization. Do these
links
>occur frequently? What kind of asymmetry do you see?

We are mainly thinking of systems with a broadband broadcast downlink
(Satellite or Digital Audio/Video Broadcast) and a narrow uplink (serial

modem or cellular). In these systems you know your bottleneck link, and
it is frequently placed close to the receiving host. Using 30 MBs DVB as

downlink and 10 kbs GSM as uplink we have a raw bandwidth asymmetry
of 3000. Considering 1500 byte data packets and 40 byte ACK packets
the remaining effective bandwidth asymmetry is 80. If a simultanous
uplink data flow is competing for bandwidth the situation gets worse.

>> The compressor concatenates and compresses ACKs belonging to the
>> same TCP-connection. We add information about queue-arrival-time
>> of the concatenated ACKs. The decompressor then recreates the
original
>> ACKs and sends them uplink with the same intervals as they arrived at

>> the bottleneck queue.
>
>What about path diversity? It sounds like you are assuming that the
same
>compressor always talks to the same decompressor. You are running into
the
>same architectural risks that PEPs do (I haven't even mentioned IPSEC).

In the implementation we are thinking about right now we use a static
template at the decompressor, so the compressor needs to now which
decompressor will get the packet.

In principle you could include one full header in each
concatenated/compressed
ACK and still get reasonable compression. Then the decompressor needs no

state information at all, and any decompressor will do the job.

>>
>> We believe that our method could be mentioned in the asymmetry-draft
>> and are open for discussions.
>>
>
>I'd like to hear more details on the mail list first.
>
>--aaron