Subject: [dispatch] Review of two drafts refreshing the use of TLS with NNTP

From: Julien ÉLIE <[email-masked]>
Date: Mon, 12 Sep 2016 22:38:15 +0200

Hi all,

As you may already know, TLS-level compression will be removed from the 
next version of the TLS protocol (currently named TLS 1.3) whereas NNTP 
was relying on this feature (as we can read it in the abstract of RFC 
4642, dealing with the use of TLS with NNTP).
In order to refresh RFC 4642 to be consistent with the latest published 
RFCs about TLS, I suggest two drafts:

- one that defines an NNTP extension to allow a connection to be 
compressed (inspired from the IMAP COMPRESS command defined in RFC 4978):
     https://tools.ietf.org/html/draft-murchison-nntp-compress-05

- one that toilets all obsolete TLS-related stuff, in discrepancy with 
latest RFCs and UTA BCP 195:
     https://tools.ietf.org/html/draft-elie-nntp-tls-recommendations-01

In case some of you are interested and have time to review these drafts, 
do not hesitate to send your comments.

For your information, Alexey is considering AD-sponsoring them.  IETF 
Last Call has been sent for draft-murchison-nntp-compress-05 today, and 
draft-elie-nntp-tls-recommendations-01 will probably be also reviewed by 
people in the UTA WG.

P.-S.:  I've just seen that RFC 6648 deprecates the use of the "X-" 
prefix in application protocols.  I bet it should be taken into account 
in the examples of Section 2.1 and 2.2.3 (X-SHRINK) as well as in 
Section 7.1 of draft-murchison-nntp-compress-05.

Thanks beforehand for your valuable comments about these drafts.

-- 
Julien ÉLIE

« C'est une liqueur de grain distillée en Calédonie. » (Astérix)

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2016 13:54:17 -0000

>do not hesitate to send your comments.

I've looked at them, and they seem fine to me.  Section 3 in the
Murchison draft, offering advice on how to tune your compression,
strikes me as premature overoptimization, but since it only affects
compression efficiency, not interop, it's not very important.

R's,
John

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 13 Sep 2016 21:28:44 +0200

Hi John,

> compression efficiency, not interop, it's not very important.

Thanks for having looked at the drafts.
Maybe Section 3.1 should directly begin Section 3 (dealing with 
interoperability), and the current begin of Section 3 (advice of 
optimization) be an Appendix?

-- 
Julien ÉLIE

« Nigro notanda lapillo. » (Catulle)

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2016 20:11:42 -0000

>optimization) be an Appendix?

It's not clear in all of section 3 whether the advice is based on
observations of how traffic actually compresses, or guesses about what
will happen.  Do you know which it is?  If it's observation, the whole
section can stay.  If it's guesses, the whole section should go.

R's,
John

---

From: Julien ÉLIE <[email-masked]>
Date: Tue, 13 Sep 2016 22:59:36 +0200

Hi John,

> will happen.  Do you know which it is?

I ran some tests last year about compression ratios, and Bo Lindbergh 
about the use of different flush options:
   https://groups.google.com/forum/#!topic/news.software.nntp/ZXrwlcAUMMM
   (thread beginning with Message-ID <[email-masked]>)

Netnews articles are pretty similar to e-mails, so it is not surprising 
to find a performance similar to what Section 4 of RFC 4978 (COMPRESS 
for IMAP) mentioned.

When we say that "responses not related to article header/body retrieval 
(e.g, CAPABILITIES, GROUP, LISTGROUP, LAST, NEXT, STAT, DATE, NEWNEWS, 
NEWGROUPS, LIST, CHECK [RFC4644], etc) are highly compressible; zlib 
using its least CPU-intensive setting compresses typical responses to 
25-40% of their original size."

We for instance have:

LIST ACTIVE answer
Uncompressed:  1393931 bytes
Compressed with level 1:  394856 bytes (28%)
[...]
Compressed with level 9:  314809 bytes (22%)

LIST NEWSGROUPS answer
Uncompressed:  2564921 bytes
Compressed with level 1:  836486 bytes (32%)
[...]
Compressed with level 9:  718244 bytes (28%)

LISTGROUP answer
Uncompressed:  53793 bytes
Compressed with level 1:  20177 bytes (37%)
[...]
Compressed with level 9:  20329 bytes (37%)

NEWNEWS answer
Uncompressed:  474178 bytes
Compressed with level 1:  147513 bytes (31%)
[...]
Compressed with level 9:  128067 bytes (27%)

These are the most used commands in question, and the ratio is 25-40% 
for level 1.
Maybe in the list given in example of commands, we should drop 1-line 
answers that in fact won't save many bytes.  We're speaking of 30 bytes 
or like answers...  And they are not compressed to 10 bytes, but as 
often as not remain of the same size, or are 70-100% compressed.
Let's just keep LISTGROUP, NEWNEWS, NEWGROUPS and LIST for clarity.  No 
need to list all existing NNTP commands!

And for Base64 attachments, the result is not surprising:
Uncompressed:  13710605 bytes
Compressed with level 1:  10532602 bytes (76%)
[...]
Compressed with level 9:  10357010 bytes (75%)

> If it's observation, the whole section can stay.  If it's guesses,
> the whole section should go.

We can then keep it in Section 3 instead of an Appendix.

-- 
Julien ÉLIE