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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 2 Jul 2019 09:24:46 +0200

Dear WG,

Please find below the pointers to a new Internet Draft that describes a
simple "ACK Pull" mechanism, intended to improve performance in a number
of scenarios / use cases.

Comments are very much welcome.

Thanks,

Carles and Jon

---------------------------- Original Message ----------------------------
Subject: New Version Notification for draft-gomez-tcpm-ack-pull-00.txt
From:    [email-masked]
Date:    Mon, July 1, 2019 5:08 pm
To:      "Jon Crowcroft" <[email-masked]>
         "Carles Gomez" <[email-masked]>
--------------------------------------------------------------------------

A new version of I-D, draft-gomez-tcpm-ack-pull-00.txt
has been successfully submitted by Carles Gomez and posted to the
IETF repository.

Name:		draft-gomez-tcpm-ack-pull
Revision:	00
Title:		TCP ACK Pull
Document date:	2019-07-01
Group:		Individual Submission
Pages:		6
URL:           
https://www.ietf.org/internet-drafts/draft-gomez-tcpm-ack-pull-00.txt
Status:         https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/
Htmlized:       https://tools.ietf.org/html/draft-gomez-tcpm-ack-pull-00
Htmlized:      
https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-pull

Abstract:
   Delayed Acknowledgments (ACKs) allow reducing protocol overhead in
   many scenarios.  However, in some cases, Delayed ACKs may
   significantly degrade network and device performance in terms of link
   utilization, latency, memory usage and/or energy consumption.  This
   document defines the TCP ACK Pull (AKP) mechanism, which allows a
   sender to request the ACK for a data segment to be sent without
   additional delay by the receiver.  AKP makes use of one of the
   reserved bits in the TCP header, which is defined in this
   specification as the AKP flag.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 16 Jul 2019 23:58:48 -0700

Hi Carles,

Thanks for the draft. I think understand the motivation, although I think
using a reserved flag is a bit expensive as it's sparse resource.
I am thinking utilizing MAD option proposal
(draft-wang-tcpm-low-latency-opt-00) might be another option for this.
If we know the maximum ACK delay values from this option and sender's
window size is one MSS, we can set a certain sleep timer for sender after
transmitting a packet.
This may be able to save the battery on the sender side.

Thanks,
--
Yoshi

On Tue, Jul 2, 2019 at 12:25 AM Carles Gomez Montenegro <
[email-masked]> wrote:

> Status:
> https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-pull/
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Jul 2019 09:56:06 +0200

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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 17 Jul 2019 13:06:20 +0200

> On 17. Jul 2019, at 09:56, Carsten Bormann <[email-masked]> wrote:
> 
Could you define what you mean by "what used to be the PSH semantics"?
> They are close enough anyway…
Hmm. My understanding of the OSH semantic is that it might trigger a local
behaviour on the receiver side: Deliver data to the application.
The AKP semantic is to trigger an behaviour on the network: send an ACK segment.

Best regards
Michael