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

["Carles Gomez Montenegro" <[e-mail]>]

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



> On Wed, Jul 17, 2019 at 9:53 AM Neal Cardwell
> <ncardwell=[e-mail]> wrote:
>>
>> 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.
> +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.
>
>
>>
>> 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=[e-mail]> 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 <[e-mail]> On Behalf Of Michael Tuexen
>> > Sent: Wednesday, July 17, 2019 6:41 AM
>> > To: Scharf, Michael <[e-mail]>
>> > Cc: [e-mail] Extensions <[e-mail]>;
>> [e-mail]
>> > Subject: Re: [tcpm] [Fwd: New Version Notification for
>> draft-gomez-tcpm-ack-pull-00.txt]
>> >
>> > > On 17. Jul 2019, at 14:44, Scharf, Michael
>> <[e-mail]> 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: [e-mail]; [e-mail] 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 <[e-mail]>
>> 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