Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt]

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 17 Jul 2019 12:44:55 +0000

Is my understanding correct that this could be formalized as follows:

  A TCP MAY not delay ACKs for data segments with the PSH flag.

If that was the intention, I believe that the wording of RFC 1122 (and draft-ietf-tcpm-rfc793bis) would allow such a receiver-side heuristic already. Delayed ACKs are a SHOULD in RFC 1122 and the exact logic is not specified. Thus, taking the PSH flag into account inside a receiver-side delayed ACK heuristic may not even be a change of the TCP semantics…

Michael

Von: Carsten Bormann<mailto:[email-masked]>
Gesendet: Mittwoch, 17. Juli 2019 09:56
An: Yoshifumi Nishida<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked] Extensions<mailto:[email-masked]>
Betreff: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt]

On Jul 17, 2019, at 08:58, Yoshifumi Nishida <[email-masked]> wrote:
>
>  using a reserved flag is a bit expensive

The option could simply redefine existing PSH as having the AKP semantics.
(And possibly all packets having what used to be the PSH semantics.)
They are close enough anyway…

Grüße, Carsten

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 17 Jul 2019 15:40:52 +0200

> On 17. Jul 2019, at 14:44, Scharf, Michael <[email-masked]> wrote:
> 
I think this is what Carsten was referring to.

My point was: Is this already deployed?

The reason I'm asking is that I have heard several time that the semantic of the
PSH bit is to send out an ACK immediately. I could not find the source of this
statement...

Best regards
Michael
> Von: Carsten Bormann
> An: Yoshifumi Nishida
> Cc: [email-masked]; [email-masked] Extensions

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 17 Jul 2019 16:21:37 +0000

Windows TCP on sender side will set PSH at the message boundary i.e. when it finishes generating sends as part of a posted send() API call or equivalent. On receiver side however it does not generated immediate ACK upon receiving PSH. IIRC Linux also sets PSH on sendmsg() boundary. Not sure about other implementations. If most major implementations are doing this then generating immediate ACK upon PSH will be an improvement. 

I do think reusing PSH to require eliciting ACKs is a reasonable alternative than using up a reserved bit. One concern with both the original draft and the PSH proposal is that we'll need clear recommendations on when a receiver will request this. Otherwise (selfish) receivers will always request it and senders will have to build complicated heuristics to detect such behavior and fall back to doing delayed ACKs. 

-----Original Message-----
From: tcpm <[email-masked]> On Behalf Of Michael Tuexen
Sent: Wednesday, July 17, 2019 6:41 AM
To: Scharf, Michael <[email-masked]>
Cc: [email-masked] Extensions <[email-masked]>; [email-masked]
Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt]

The reason I'm asking is that I have heard several time that the semantic of the PSH bit is to send out an ACK immediately. I could not find the source of this statement...

Best regards
Michael
>  
> If that was the intention, I believe that the wording of RFC 1122 (and 
> draft-ietf-tcpm-rfc793bis) would allow such a receiver-side heuristic 
> already. Delayed ACKs are a SHOULD in RFC 1122 and the exact logic is 
> not specified. Thus, taking the PSH flag into account inside a 
> receiver-side delayed ACK heuristic may not even be a change of the 
> TCP semantics…
>  
> Michael
>  
>  
> Von: Carsten Bormann
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40micros
> oft.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C636989676733913763&amp;sdata=YxD0gSXU6owQeXgKqYp462j
> mS9ihLrI5RDocqpS8CfQ%3D&amp;reserved=0
>  
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40micros
> oft.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C636989676733913763&amp;sdata=YxD0gSXU6owQeXgKqYp462j
> mS9ihLrI5RDocqpS8CfQ%3D&amp;reserved=0

_______________________________________________
tcpm mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cbfdb4e02ba524e0c707408d70abc6d1e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636989676733923755&amp;sdata=DLucPcy4x04sZslmF8Egm9BiggxVxu5gCuW%2F8T70yQo%3D&amp;reserved=0

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 17 Jul 2019 12:52:49 -0400

Indeed, Linux also does not generate an immediate ACK upon receiving
PSH, and also sets PSH on sendmsg() boundaries.

One perspective I am not sure has been discussed in this thread: Those
behaviors to generate PSH on sendmsg() boundaries are widely deployed.
There are lots of workloads that have a large number of small packets
with PSH set (RPC, web, ...). If we change the semantics of PSH to
cause an immediate ACK, then we will effectively turn off delayed ACK
acks for many RPC and web workloads. This will increase CPU and
network loads for such workloads. For some RPC workloads it would
double the number of packets  sent by servers (the server would now
send 1 ACK for every request, and then 1 response packet, instead of
piggybacking ACKs and replies). That cost has to be weighed against
any latency advantages.

Using a new bit would have the advantage of allowing senders to only
force more ACKs when their available cwnd or rwnd is low enough that
they need an immediate ACK to allow good performance.

Just a thought.

cheers,
neal

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 17 Jul 2019 10:31:27 -0700

> piggybacking ACKs and replies). That cost has to be weighed against
+1 on similar concern.

It's worth noting a recent issue we discovered while testing BBRv2
which uses DCTCP-ECN protocol. The Linux delayed-ACK implementation does not
always ACK every other data packet. It may delay sending an ACK until
the available receive window has at least matched or grown beyond to
the previous window announced. Under heavy (data-path) network
congestion, a slower receiver could frequently delay the ACKs when
most data packets have CE marks.

This ACK delay causes the sender to further slow down in additional to
the CE events being returned since both BBRv2 and DCTCP are still
ACK-clocked. The large RPC is received more slowly (compared to a
policy that acks immediately every other packet). The application
goodput is zero until the RPC is finally completely received. This
cause much longer RPC tail latency visible to the users. So this
design causes all RPCs to progress more slowly in parallel, vs fewer
RPCs to progress more quickly in serial.

Arguably this is an implementation / optimization issue, but I think
it's very relevant to this thread. Neal may talk about that in the
upcoming ICCRG bbr.v2 talk.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 19 Jul 2019 11:41:52 +0200

Hello everyone,

Thanks a lot for all the suggestions and feedback provided.

Assessing the pros and cons of the alternatives on the table (in the light
of, but perhaps not limited to, the considerations already expressed on
the list) will be an important next step.

I plan to include a summary of the discussion so far in my presentation in
Montreal.

Looking forward to continuing the discussion,

Carles

>> > Windows TCP on sender side will set PSH at the message boundary i.e.
>> when it finishes generating sends as part of a posted send() API call
>> or equivalent. On receiver side however it does not generated
>> immediate ACK upon receiving PSH. IIRC Linux also sets PSH on
>> sendmsg() boundary. Not sure about other implementations. If most
>> major implementations are doing this then generating immediate ACK
>> upon PSH will be an improvement.
>> >
>> > I do think reusing PSH to require eliciting ACKs is a reasonable
>> alternative than using up a reserved bit. One concern with both the
>> original draft and the PSH proposal is that we'll need clear
>> recommendations on when a receiver will request this. Otherwise
>> (selfish) receivers will always request it and senders will have to
>> build complicated heuristics to detect such behavior and fall back to
>> doing delayed ACKs.
>> >
>> > The reason I'm asking is that I have heard several time that the
>> semantic of the PSH bit is to send out an ACK immediately. I could not
>> find the source of this statement...
>> >
>> > Best regards
>> > Michael
>> > >