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

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

> -----Original Message-----
> From: Andre Oppermann [mailto:[email-masked]] 
> Sent: Wednesday, November 15, 2006 9:57 AM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]
> Subject: Re: [tcpm] Proposing ACKNOW bit in TCP header
> 
> Anantha Ramaiah (ananth) wrote:
> > 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?
> 
> Turning delayed ACK off is perfectly legal.  Doing/supporting 
> delayed ACK is a SHOULD in RFC2581.

I understand it is a SHOULD. I was thinking in much more simpler terms.
Typically the delayed ACK is :
- either a system wide knob OR
- a per connection TCP property.
In both cases with the ACKNOW we would be changing the behaviour by
*not* waiting for 200ms. This is something we don't want to encourage
through the back door (via ACKNOW). 

Even if the delayed ACK is turned off, some stacks have the ACK policy
of ACK every n segments where n = 2 (sometimes 4). The ACKNOW would
change this without applications knowledge. While it may seem simple,
this would lead to a nightmare in troubleshooting RTT issues and there
are applications out there which use TCP probes to calculate end to end
delays.

IMO your draft needs to spell out this clearly about the ramifications
of such a behaviour, since you use a "MUST" clause.

Just to clarify : If the receiver has data already to be sent, it MUST
piggyback it and shouldn't blindly honor ACKNOW. This is not explicit
and I assume you would state this in the draft.

-Anantha

<snip>

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

---

From: Andre Oppermann <[email-masked]>
Date: Wed, 15 Nov 2006 21:02:41 +0100

> through the back door (via ACKNOW). 

Why not in those cases where it would provide benefits?  Delayed ACK
is a tradeoff which at the moment is static.  ACKNOW gives the option
to take away the negative sides to it.

For reference: maximal legal delACK time is 500ms.

> are applications out there which use TCP probes to calculate end to end

The idea of TCP is that it should be transparent to the application
using it.  Any time an application has to fiddle with TCP internals
it's a bug.  Unfortunately in reality sometimes the application has
to make it's intent more clear by setting 'NO_DELAY' or such.  These
should be the exceptions.  Using a TCP probe to measure end to end
delays is highly difficult anyway as you never know what you measure;
the network delay or the artificial ACK delay and its variance.  And
TCP never guarantees you that when the write() call returns your data
actually appeared on the wire.  It may as well sit in the send buffer
waiting for clearance.  I've tried to accurately measure the real
network RTT in the kernel based on TCP ACKs and timestamps and it is
not possible unless you have long steady state bulk transfers.
Unfortunately by the time reach that plateau it doesn't have that
much value anymore.

> of such a behaviour, since you use a "MUST" clause.

Agreed. :-)

> and I assume you would state this in the draft.

Indeed.

-- 
Andre