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

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

On Wed, Jul 17, 2019 at 12:21 PM Praveen Balasubramanian
<pravb=40microsoft.com@dmarc.ietf.org> wrote:
>
> 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 <tcpm-bounces@ietf.org> On Behalf Of Michael Tuexen
> Sent: Wednesday, July 17, 2019 6:41 AM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Cc: tcpm@ietf.org Extensions <tcpm@ietf.org>; jon.crowcroft@cl.cam.ac.uk
> Subject: Re: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt]
>
> > On 17. Jul 2019, at 14:44, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> >
> > Is my understanding correct that this could be formalized as follows:
> >
> >   A TCP MAY not delay ACKs for data segments with the PSH flag.
> 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
> >
> > 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
> > Gesendet: Mittwoch, 17. Juli 2019 09:56
> > An: Yoshifumi Nishida
> > Cc: jon.crowcroft@cl.cam.ac.uk; tcpm@ietf.org Extensions
> > Betreff: Re: [tcpm] [Fwd: New Version Notification for
> > draft-gomez-tcpm-ack-pull-00.txt]
> >
> > On Jul 17, 2019, at 08:58, Yoshifumi Nishida <nsd.ietf@gmail.com> 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
> > tcpm@ietf.org
> > 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
> > tcpm@ietf.org
> > 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
> tcpm@ietf.org
> 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
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm