Subject: Re: Compressed ACKs and ACK Compaction

From: Goran Johansson <[email-masked]>
Date: Tue, 19 Oct 1999 09:50:49 +0200

Hari Balakrishnan and Dr Fairhurst,

we are happy to see that other people are working on similar ideas!
Unfortunately we had not seen Dr Fairhurst's publication before, but we
find it very interesting.

Dr Fairhurst wrote:
>The additional information carried
> in the ACK stream is to ensure conservative behaviour.

We agree with this statement and would like to ask Hari Balakrishnan:

If you do not send any information about the number of ACKs you
have thrown away, or compacted, could you be sure never to
recreate too many ACKs, i.e. could you be sure never to be
more agressive than TCP would have been over symmetric links?

Dr Fairhurst also wrote:
>One thing that always worried me was the impact of SACK - have you a
>scheme proposed which would accommodate this sensibly?

We also agree with this, and will implement the "recreation" of both
Timestamp and SACK options. In fact we also intend to recreate the bits
that may be used for ECN which we like to support

Hari Balakrishnan wrote to Dr Fairhurst:
>Both your scheme and the one outlined by Goran require that information
be
>carried in the header.  Obviously, with this information, you can
*potentially*
>do better.  But I wonder if you really need it---if the reconstructor
can adapt
>without it and do quite well, why add this complexity and protocol for
it?

We grant you the benefit from not requiring a new protocol and for
transferring less data over the bottleneck link.

However, in addition to the question of number of acks above, we wonder
what impact of competing traffic you anticipate on the (temporal) ack
spacing? Could not the acknowledgement arrival time at the ack
reconstructor
depend more on competing traffic than on the transmission time from the
data receiving host?

///Göran/Haider/Jan