Subject: RE: [tcpm] Proposing ACKNOW bit in TCP header

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Wed, 15 Nov 2006 08:53:15 -0800

Andre,
   Few observations :

A) What happens if the sender tries to set the ACKNOW bit for every
packet? I assume it is like as if the delayed ACK is completely turned
off. I am not sure if this is acceptable. In other words how would you
enforce which packet (segment to be precise) needs this special
treatment? Or can the receiver chose to ignore the ACKNOW setting?

B) The general feeling which I have gathered is that : the bits in the
TCP header is a very scarce resource and the case for using need to be
strong. See below..

C) Why can't you use TCP option? TCP option is scarce as well, but there
have been some interest to extend them, atleast. Typically after
complete processing the TCP header is done (which includes the TCP
options, if the packet contains TCP options) the ACK gets sent. Some
stacks have overloaded the header prediction functionality to include
processing of TCP options. (atleast the important ones)

Gernerally the TCP header bits are used for control messages (SYN, FIN,
RST, ACK, URG) but the one which you are proposing sounds like a more
fit in the TCP option space.. 

Anyways just a few thoughts, given the first read.

-Anantha 

> -----Original Message-----
> From: Andre Oppermann [mailto:[email-masked]] 
> Sent: Wednesday, November 15, 2006 5:00 AM
> To: [email-masked]
> Subject: [tcpm] Proposing ACKNOW bit in TCP header
> 
> I propose to include an ACKNOW bit into the TCP header 
> instructing the recipient to immediately, without any delay 
> whatsoever, acknowledge the received segment.  The bit 
> location is the 9th bit in the TCP flags.
> This bit is to be included in TCP SYN segments to indicate 
> the support for it.  Only if the SYN-ACK response has the bit 
> set as well the session is allowed to make use of the ACKNOW feature.
> 
> Rationale:
> 
> During the slow start and congestion recovery phases the 
> sender is dependent on immediate feedback to quickly make 
> optimal use of all network resources again.  The presence of 
> delayed ACKs add unnecessary delays and introduces 
> uncertainty to the recovery progress and the discovery of the 
> true network conditions.  On the other hand delayed ACKs 
> serve an important function on fast networks with high PPS 
> rates to improve efficiency and to coalesce the acknowledging 
> of multiple segments at once.  It is extremely difficult for 
> the receiver to guess itself when to switch from delayed ACKs 
> to immediate ACKs as it has only insufficient hints the 
> current state the sender operates in.
> 
> The ACKNOW flag solves this in a simple and elegant way by 
> allowing the sender to explicitly request an immediate ACK to 
> its segments when it is appropriate for the congestion 
> control recovery mechanism to do so.
> As a second benefit a receiver on a ACKNOW flag enabled 
> session may increase the delayed ACK from every other packet 
> (as currently required) to a higher number, lets say every 
> eighth.  The exact value is to be determined based on the 
> estimated delay*bandwidth product and the send/ receive 
> socket buffer sizes.
> 
> The use of the ACKNOW bit allows significant faster recovery 
> times in the presence of difficult network conditions.
> 
> --
> Andre
> 
> <[email-masked]>
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm
> 

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Andre Oppermann <[email-masked]>
Date: Wed, 15 Nov 2006 18:57:16 +0100

> treatment? Or can the receiver chose to ignore the ACKNOW setting?

Turning delayed ACK off is perfectly legal.  Doing/supporting delayed
ACK is a SHOULD in RFC2581.

With ACKNOW a receiver MUST send an ACK for every segment it received
with this flag turned on.  A low power/memory system may find this
beneficial as it may only be able to hold one outstanding segment in
the send buffer.  Nanoprobes on wireless networks spring to mind.

There is no DoS potential with ACKNOW.  The sender may only cause one
ACK reply per segment he sends.  There is no amplification effect.
It's sub-optimal but it's not fatal or dangerous in any way.

> TCP header is a very scarce resource and the case for using need to be

ACKNOW is a single flag and really suite to be placed in the TCP header.
ACKNOW has real tangible benefits which are quickly and easily realized.
ECN got not one but two bits in the TCP header with much less to show
for.

> processing of TCP options. (atleast the important ones)

Any new TCP option causes much more overhead and waste.  It consumes at
least two full bytes in the SYN/SYN-ACK and every packet that sets it.
That is seven bytes wasted on a quite scarce resource too.

-- 
Andre