Subject: RE: draft-ietf-pilc-asym-00.txt

From: Mikael Degermark <[email-masked]>
Date: Thu, 14 Oct 1999 19:03:07 +0200

I don't belive that Gorans scheme, judging from what he's 
told on this list, is any more or any less problematic than 
standard header compression.

I don't quite understand how the acks are being played back
by the decompressor, though. Are all acks delayed the same
amount? (I.e., departure time = arrival time in compressor's 
queue + K, where K is the one-way delay across the link)

If so, is K the same for all acks, or is it only the
same for the acks compressed into the same aggregated ack?

Micke

At 11:06 AM 10/14/99 -0400, Falk, Aaron 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?
>
>> 
>> 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?
>
>> 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).
>
>> 
>> 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
>
>

http://www.cdt.luth.se/~micke