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

From: janaiyengar <[email-masked]>
Date: Wed, 28 Nov 2018 18:25:10 -0800

You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2068

-- Commit Summary --

  * PING is reliably delivered

-- File Changes --

    M draft-ietf-quic-transport.md (32)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2068.patch
https://github.com/quicwg/base-drafts/pull/2068.diff

-- 
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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Nov 2018 18:32:52 -0800

martinthomson commented on this pull request.

It's acknowledged, but PING is curiously absent from the retransmission rules.

I don't think that we should assume that PING needs to be sent again if the packet containing it is lost.  The point of PING is to elicit acknowledgment.  Whether that is for a specific packet or just for the connection in general, it shouldn't matter to us.

-- 
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-179607307

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Nov 2018 18:33:43 -0800

Based on this, I would suggest we have a new issue that this can maybe address.

-- 
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-442683977

---

From: janaiyengar <[email-masked]>
Date: Wed, 28 Nov 2018 18:50:01 -0800

PING was always supposed to be reliably delivered... if that changed, I missed it. Do you remember it being different?  (I could be losing it, which is not entirely out of the question.)

-- 
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-442686833

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Nov 2018 18:52:05 -0800

I only have what is written down.  And right now, nothing is.  I think that we used to say that it was reliably sent, but we lost that.  And I'm not sad about it.  Whether or not it was intended to be reliably delivered, I can see a use for not having it so - so why not let the sender decide?

-- 
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-442687220

---

From: janaiyengar <[email-masked]>
Date: Wed, 28 Nov 2018 18:54:14 -0800

I'm actually not opposed to it... I think it is sensible to let the sender decide. Either ways, we should have something in retransmission rules about 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-442687583

---

From: janaiyengar <[email-masked]>
Date: Wed, 28 Nov 2018 18:55:18 -0800

Even then, the statement isn't accurate. An endpoint could decide to use PING as a reliable frame if it chooses, which would make the claim in the current text an overreach.

-- 
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-442687753

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Nov 2018 18:58:01 -0800

Sure, but you could easy change the text to "These frames are do not need to be retransmitted if they are lost."

-- 
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-442688210

---

From: MikkelFJ <[email-masked]>
Date: Thu, 29 Nov 2018 07:49:18 +0000 (UTC)

Making the sender decide to retransmit a PING makes it hard to use PING in different parts of the spec precisely and it also makes it hard to use for applications. If a reliable PING is needed it should probably be a separate frame, or it should be reliable and we could a separate PROBE frame.

-- 
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-442737980

---

From: Mike Bishop <[email-masked]>
Date: Thu, 29 Nov 2018 09:20:00 -0800

We have a separate PROBE frame; it's called PATH_CHALLENGE.

I think we've said previously that PADDING and PING have identical semantics (to wit, none), except that PING forces the packet to be acknowledged regardless of whether there's anything retransmittable in that packet.  Whether we want it to have that property because it's reliably transmitted or because it's not either ACK or PADDING seems like a philosophical discussion akin to how many angels could dance on the head of a pin.

FWIW, it delivers no information when delivered; I see no point in delivering it reliably.  It elicits an ACK if the packet arrives -- that is a sufficient purpose.

-- 
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-442918679

---

From: MikkelFJ <[email-masked]>
Date: Thu, 29 Nov 2018 18:10:43 +0000 (UTC)

I don't care about the number of angels, as long as it isn't implementation dependent.

-- 
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-442935816

---

From: ianswett <[email-masked]>
Date: Thu, 29 Nov 2018 11:51:22 -0800

PING frames are "retransmittable", but there's no need to make them reliable at the transport layer, so I don't think we should specify they are.

For PMTU, if the first packet is lost, I can definitely see the sender not sending another PING.

-- 
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-442969992

---

From: MikkelFJ <[email-masked]>
Date: Thu, 29 Nov 2018 12:31:01 -0800

If PING can randomly be retransmitted but does not have to, PING is useless to the application.

If PING is never retransmitted, the application can use that signal for its own purposes such as QoS montoring.

If PING is always retransmitted, the application can use that to make sure a connection stays alive by sending one once in a while.

I don't really care either way, as long is it is one or the other. The the missing alternative can be added later as a new frame if important enough.

-- 
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-442982370

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 30 Nov 2018 04:49:33 -0800

@mikkelfj To me that sounds like an API issue rather than a protocol design issue.

Current specification of PING does not require it to be retransmitted. However, the fact does not prohibit the developers of QUIC stack from providing an API that retransmits PING frames to test if the peer is alive.

-- 
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-443194053

---

From: MikkelFJ <[email-masked]>
Date: Fri, 30 Nov 2018 09:23:06 -0800

@kazuho It is not an API issue: you cannot design an application layer protocol around PING without knowing about retransmission. For one thing it won't work if you app is too tightly coupled to one implementation, and second, you cannot make assumptions about receiving pings because you don't know if it was a retransmission.

I think some things are fine to leave to the API, such as very special things like partial delivery of streams with gaps, but you couldn't make H3 based on such assumptions, as an example. Having PING unspecified makes it unusable for general application design.

Also, it makes keep alive very error prone since you might incorrectly assume that sending ping will ensure keep alive, but in fact it only work that way for some implementations.

-- 
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-443276021

---

From: Mike Bishop <[email-masked]>
Date: Fri, 30 Nov 2018 09:40:45 -0800

MikeBishop approved 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

"these aforementioned" seems redundant.  Either "these mechanisms" (the original) or "the aforementioned mechanisms," though that sounds over-formal.

-- 
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-180373958

---

From: hardie <[email-masked]>
Date: Fri, 30 Nov 2018 14:57:42 -0800

On Thu, Nov 29, 2018 at 12:30 PM MikkelFJ <[email-masked]> wrote:

> If PING is always retransmitted, the application can use that to make sure
> a connection stays alive by sending one once in a while.
>

For the heartbeat case, it seems like the application could send a PING
frame and continue to send new PING frames until one is acknowledged (since
they must be acknowledged).  I agree, though, that is a pretty wasteful set
of affairs if you're going to need to send a lot of heartbeats.  I don't
think that strategy for maintain a stable 5 tuple is as necessary with
QUIC, though, so the trade-off looks like this to me:

Case 1:

1)PING MUST be acknowledged but is not re-transmitted, so a lack of
acknowledgement is a clear signal of loss on the path.

2) If you want a heartbeat, you send fresh PINGs until  you get an
acknowledgement of one of them (and count the ones that did not get
acknowledged as lost).

Case 2:

1) PING MUST be acknowledged and MUST be re-transmitted, so a single PING
is sufficient to create a heartbeat for the connection/application.

2) Each re-transmission is a signal of either loss or significant delay
along the path.

If we think heartbeats over lossy connections are going to be common, I'd
go with two.  If we don't, I'd go with one.  I agree that having "might be
retransmitted" is the worst option.

Just my two cents,

Ted

-- 
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-443365021