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

From: Alejandro Popovsky <[email-masked]>
Date: Mon, 23 Dec 2013 15:36:11 -0300

The delayed ack generation may bother when applied to the last segment 
of a burst.

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.

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.

Best regards, Alejandro.

---

From: Joe Touch <[email-masked]>
Date: Mon, 23 Dec 2013 11:11:50 -0800

> The delayed ack generation may bother when applied to the last segment

That's not clear at all - see below.

> with no tail probing (TLP), nor end of burst reordering (Scheffenegger).
>

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().

> 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
>

---

From: Mark Lloyd <[email-masked]>
Date: Mon, 30 Dec 2013 22:24:46 +0000

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

> There is no 'end of burst indication' from regular senders, i.e. 
> senders with no tail probing (TLP), nor end of burst reordering (Scheffenegger).
>
> 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().

> a/'/push' data segment coming after at least one 'non-push' data 
> segment.

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.

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.

Joe