Subject: [quicwg/base-drafts] Rename "retransmittable" frames and packets (#1595)

From: ianswett <[email-masked]>
Date: Mon, 23 Jul 2018 09:03:00 -0700

The word retransmittable is used in the recovery draft for both frames and packets that cause an ACK frame to be sent in response to their receipt.

This is really misleading, because QUIC never retransmits packets(except maybe connection close) and only sometimes retransmits frames.

Ideally we'd have different words for the frames and the packets containing those frames, but at a minimum I want to stop using retransmittable.

Previous suggestions:
- Ackable - I didn't like this before, but it's strictly better than retransmittable.
- Reliable - Maybe a good term for packets, less good for frames?
- Needs Acknowledgement - Verbose, but correct.  Possibly abbreviated to Nack for maximum confusion :)
- Persistent

I'm want to change retransmittable to something else before the next drafts, so please suggest alternatives now and I'll write a PR for whatever people hate the least.

-- 
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/issues/1595

---

From: Nick Banks <[email-masked]>
Date: Mon, 23 Jul 2018 09:07:22 -0700

I'd throw my vote to **Reliable**. Reliable frames contain data/information that needs to be reliably delivered. and reliable packets contain reliable frames.

-- 
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/issues/1595#issuecomment-407112174

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 23 Jul 2018 09:10:21 -0700

- Wants Acknowledgement - Wack
- Acknowledgement Required - Ackr
- Receipt Required - RecReq

:~)

-- 
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/issues/1595#issuecomment-407113094

---

From: MikkelFJ <[email-masked]>
Date: Mon, 23 Jul 2018 10:27:06 -0700

Reliable frames are no good - they are not reliable at all. They get lost and are never seen again.

Committed frames convey the fact that once they are sent, they are committed to get the information delivered either by themselves or by those that follow in its path. Not necessarily the same information, but at least the same kind. It's like a treaty where one government honors decistions of past governments (but of course not all governments are commited and the same is true for frames).

-- 
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/issues/1595#issuecomment-407136957

---

From: ianswett <[email-masked]>
Date: Mon, 23 Jul 2018 10:37:00 -0700

Ooh, I like Wack frames.

-- 
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/issues/1595#issuecomment-407139971

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 24 Jul 2018 00:33:23 -0700

I'd prefer something like "ACK-eliciting".

In my view, it should rather _not_ be called "ACKable", because even an ACK frame expects an acknowledgement. IIUC, we are looking for a term for frames that invokes an early acknowledgement.

I am not sure if "reliable" or "committed" is a good term, because we have PING, which is not something that is guaranteed to be delivered. Instead, it is something that just elicits an acknowledgement. The sender has the total freedom of deciding whether or not to resend an PING if it does not see an acknowledgement.

-- 
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/issues/1595#issuecomment-407310232

---

From: MikkelFJ <[email-masked]>
Date: Tue, 24 Jul 2018 00:45:28 -0700

On PING:
you can have committed frames, and ACK eliciting frames, and they are mostly the same, but not always. So it makes sense to have different terms.

ACK-inducing would be an alternative to ACK-eliciting.

-- 
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/issues/1595#issuecomment-407313306

---

From: MikkelFJ <[email-masked]>
Date: Tue, 24 Jul 2018 00:49:32 -0700

On Wack:

It would be more precisely to name them Whack frames because like whack-a-mole, they keep popping up again in a new form. Mole might actually be the correct term here.

https://www.youtube.com/watch?v=VoP1E9J4jpg

-- 
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/issues/1595#issuecomment-407314351

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 Jul 2018 23:14:11 -0700

Interesting to look back at this after the discussion of flow control. Take the MAX DATA frame. It does elicit an advertisement. It may be retransmitted, but really should not. Instead, if the packet carrying the frame is lost, the "receiver" (sender of MAX DATA) should check whether it already sent a MAX DATA frame carrying a higher limit, in which case there is no need for retransmission. If the frame is the newest, it should probably still not be retransmitted as is -- there may be a need to check create a new frame containing the latest MAX DATA value. So the MAX DATA frame elicits ACKS, its loss should be detected, but how retransmission proceeds depends on the state of 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/issues/1595#issuecomment-409461160

---

From: Christian Huitema <[email-masked]>
Date: Tue, 31 Jul 2018 23:15:14 -0700

I like reliable for frames like MAX DATA, but you really need to define reliable...

-- 
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/issues/1595#issuecomment-409461345