Subject: Re: [quicwg/base-drafts] PING is reliably delivered (#2068)

From: Christian Huitema <[email-masked]>
Date: Sat, 01 Dec 2018 22:28:05 -0800

Wait a minute. I have currently an implementation of PMTU discovery. To test a possible PMTU value, I send a packet of that length, full of PING and PAD, just like the text says. I do expect the packet to be acknowledged if it is received. If the packet is not acknowledged, I will probably not resend it as is. I may or may not try a different PMTU. I may wait for some time. I am definitely not going to automatically retransmit "the PING frame".

For me, the PING frame is a transport level construct, just like ACK or PAD. I don't think that the application API should specify "send a PING frame". It should most probably be something like "test whether the connection is still up, and tell me in not less than 3 RTT". Or something like that. And then the transport logic implements that however they see fit.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#issuecomment-443485146

---

From: Christian Huitema <[email-masked]>
Date: Sat, 01 Dec 2018 22:30:53 -0800

By the way, the actual text of the PR is fine. It is just the title that is weird.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#issuecomment-443485241

---

From: MikkelFJ <[email-masked]>
Date: Sun, 02 Dec 2018 01:14:19 -0800

I think we may then need some text to guide application level keep-alive design and explicitly state that PING might not be it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#issuecomment-443492903

---

From: Christian Huitema <[email-masked]>
Date: Sun, 02 Dec 2018 07:38:56 -0800

@mikkelfj The way Picoquic does it is through these API:
```
/* Enables keep alive for a connection.
 * If `interval` is `0`, it is set to `idle_timeout / 2`.
 */
void picoquic_enable_keep_alive(picoquic_cnx_t* cnx, uint64_t interval);
/* Disables keep alive for a connection. */
void picoquic_disable_keep_alive(picoquic_cnx_t* cnx);
```
If the API is enabled, the transport will in fact send PING frames, but only if there is not enough application traffic or other traffic to sustain the connection.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#issuecomment-443516804

---

From: Mike Bishop <[email-masked]>
Date: Mon, 03 Dec 2018 20:03:55 +0000 (UTC)

Sounds like I should probably reword this section in HTTP, then:
> HTTP clients are expected to use QUIC PING frames to keep connections open while there are responses outstanding for requests or server pushes. If the client is not expecting a response from the server, allowing an idle connection to time out is preferred over expending effort maintaining a connection that might not be needed. A gateway MAY use PING to maintain connections in anticipation of need rather than incur the latency cost of connection establishment to servers. Servers SHOULD NOT use PING frames to keep a connection open.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#issuecomment-443850736

---

From: janaiyengar <[email-masked]>
Date: Mon, 03 Dec 2018 18:18:00 -0800

janaiyengar commented on this pull request.

> -Layer PMTU Discovery ({{!DPLPMTUD=I-D.ietf-tsvwg-datagram-plpmtud}}), or
-implement Path MTU Discovery (PMTUD) {{!RFC1191}} {{!RFC8201}} to determine
-whether the path to a destination will support its desired message size without
-fragmentation.
-
-In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
-larger than 1280 bytes. Assuming the minimum IP header size, this results in a
-QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
-implementation MAY be more conservative in computing the QUIC maximum packet
-size to allow for unknown tunnel overheads or IP header options/extensions.
+An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery
+({{!DPLPMTUD=I-D.ietf-tsvwg-datagram-plpmtud}}) or implement Path MTU Discovery
+(PMTUD) {{!RFC1191}} {{!RFC8201}} to determine whether the path to a destination
+will support a desired message size without fragmentation.
+
+In the absence of these aforementioned mechanisms, QUIC endpoints SHOULD NOT

Yeah, something wasn't sitting right with me after I wrote that out. I'll leave it as it was.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#discussion_r238509482

---

From: janaiyengar <[email-masked]>
Date: Mon, 03 Dec 2018 18:18:35 -0800

@janaiyengar pushed 1 commit.

1f053104621da232d13b8872f586b0b9d7c90585  comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068/files/60853e5f9f5eebe83b862aa8bf6108c40b29203c..1f053104621da232d13b8872f586b0b9d7c90585

---

From: janaiyengar <[email-masked]>
Date: Mon, 03 Dec 2018 18:23:50 -0800

Ok, I've reverted some changes and left this with some minor editorial nits. I've also sent out #2094.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#issuecomment-443945843

---

From: Mike Bishop <[email-masked]>
Date: Tue, 04 Dec 2018 09:55:27 -0800

MikeBishop approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#pullrequestreview-181396220

---

From: janaiyengar <[email-masked]>
Date: Tue, 04 Dec 2018 10:09:14 -0800

Merged #2068 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2068#event-2005061732