Subject: Re: [tcpm] end of burst, delayed acks, and push flag

From: Alejandro Popovsky <[email-masked]>
Date: Thu, 02 Jan 2014 16:42:06 -0300

As Joe mentioned, disabling the ack delay at the end of bursts, would
make the senders grow the congestion window faster (when not in
congestion avoidance).

On the other side, one of the causes for spurious timeouts is the delay ack
at the end of a burst, as Jerry Chu mentioned in the minimum RTO 
discussion 
<http://www.ietf.org/mail-archive/web/tcpm/current/msg07040.html>,
so it might be beneficial to reduce them. Some have proposed a
sender modification 
<http://www.ee.ucl.ac.uk/%7Euceeips/minrto-networking07-psaras.pdf> to 
use an adaptive minimum RTO to handle the
delayed acks at the end of bursts.

Considering all these, may be a receiver modification based on push flags
could lower the spurious timeouts if used only for bursts longer than a 
minimum?

Alejandro.

On 30/12/2013 07:24 p.m., Mark Lloyd wrote:
> Is the RFC mandated super high Min-RTO time in play here?
>
> -----Original Message-----
> From: tcpm [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Monday, December 23, 2013 11:12 AM
> To: Alejandro Popovsky; [email-masked]
> Subject: Re: [tcpm] end of burst, delayed acks, and push flag
>
>
>
> On 12/23/2013 10:36 AM, Alejandro Popovsky wrote:
>> The delayed ack generation may bother when applied to the last segment
>> of a burst.
> That's not clear at all - see below.
>
>> There is no 'end of burst indication' from regular senders, i.e.
>> senders with no tail probing (TLP), nor end of burst reordering (Scheffenegger).
>>
>> But on many implementations, the operating system sets the push flag
>> when sending the last byte of a write(...) function call. So push flag
>> helps to identify the end of a burst.
> It might want to set the PUSH flag on the last write in a sequence of
> write() calls in a burst, but the PUSH flag applies to the last write() call, not to a byte within the write().
>
>> So a way to prevent the problem, could be to disable the ack delay for
>> a/'/push' data segment coming after at least one 'non-push' data
>> segment.
> First, let's assume Nagle is off, as it should be for bursty traffic.
>
> One side (named 'Alba') sends bursts packets to the other (named 'Nisar').
>
> Let's further assume that the burst is an odd number of packets (if it's even, then delayed ACK will work fine).
>
> Alba sends 1 packet to Nisar (this is the degenerate case; if it works for 1, it'll work for larger numbers).
>
> Nisar waits to ACK.
>
> One of three things happens next:
>
> 	- a timeout (500 ms later), when Nisar sends the ACK
> 	for the burst
>
> 	- Nisar has something to send to Alba, at which point
> 	Nisar will include the most recent ACK anyway (AFAICT)
>
> 	- Alba has something to send to Nisar, at which point she
> 	will send the first packet of it (because the window is
> 	always at least 3 packets)
>
> 		at which point Nisar will ACK the last burst
> 		and the new packet
>
> I.e., the only way this stalls is when Alba's window is smaller than 1 packet. Otherwise, not getting the ACK of the last bursts costs Alba at most one packet of capacity during the first round-trip of the next burst.
>
> I'm not sure that PUSH is the right way to fix this; just because it's the end of a burst doesn't mean there won't be another burst in much less than 500 ms, and using PUSH the way you describe could cause bursty sources to circumvent delayed ACK, in which case their window would grow faster than those that use delayed ACK today.
>
> I don't see how that's worth one packet.
>
> Joe
>
>> Best regards, Alejandro.
>>
>>
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Mark Lloyd <[email-masked]>
Date: Thu, 2 Jan 2014 20:30:27 +0000

MIN_RTO is worth revisiting IMHO.  The  1 second RFC mandate is largely ignored, but implementations seem afraid to go just go all the way to an RTO based on SRTT. A thorough examination and revision could provide substantial benefits to users.

From: Alejandro Popovsky [mailto:[email-masked]]
Sent: Thursday, January 02, 2014 11:42 AM
To: Mark Lloyd; Joe Touch; [email-masked]
Subject: Re: [tcpm] end of burst, delayed acks, and push flag

On the other side, one of the causes for spurious timeouts is the delay ack
at the end of a burst, as Jerry Chu mentioned in the minimum RTO discussion<http://www.ietf.org/mail-archive/web/tcpm/current/msg07040.html>,
so it might be beneficial to reduce them. Some have proposed a
sender modification<http://www.ee.ucl.ac.uk/%7Euceeips/minrto-networking07-psaras.pdf> to use an adaptive minimum RTO to handle the
delayed acks at the end of bursts.

Considering all these, may be a receiver modification based on push flags
could lower the spurious timeouts if used only for bursts longer than a minimum?

Alejandro.

-----Original Message-----

To: Alejandro Popovsky; [email-masked]<mailto:[email-masked]>

of a burst.

segment.

Nisar waits to ACK.

  for the burst

         and the new packet

Joe

Best regards, Alejandro.

tcpm mailing list

[email-masked]<mailto:[email-masked]>

tcpm mailing list

[email-masked]<mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Jan 2014 12:56:30 -0800

As I noted, the benefit is one packet per burst. And you have to assume 
that the push flag isn't already being used for other purposes.

IMO, this isn't worth the complexity.

Joe

On 1/2/2014 11:42 AM, Alejandro Popovsky wrote:
>> To: Alejandro Popovsky;[email-masked]