[tcpm] draft-moncaster-tcpm-rcv-cheat-02

[Alfred Hönes <[e-mail]>]

Hello,
thanks for updating your Internet-Draft to
draft-moncaster-tcpm-rcv-cheat-02, incorporating many of the
suggestions I had supplied in my review of rev. -01.

Studying the new version, I unfortunately found some of the
issues raised addressed incompletely, or even missed, and
some typos newly intruduced; and I also got aware of a small
number other nits not mentioned previously.

Note to readers of the list (added on proofreading):
  Item (5) below is the single non-editiorial topic discussed,
  and it might deserve further comments!
  This topic has caused me to copy this entire message to the list.


(1)   Re:  "cheating", "[dis]honest[ly]" , etc.

Whereas you have modified many of the occurrences of these
words not complying to the stated aims of the draft, a few
have been left in the text -- some apparently intentionally
(e.g., Sections 6.2.3 amd 6.3.2), some perhaps missed.
Please reconsider these parts of the text; I'll give pointers
below.

(1a)  Section 5.1

IMHO, it would be consistent with the rest of the memo
to replace "dishonest behaviour" by "non-conforming behavior"
in the second line of the second paragraph of Section 5.1.

(1b)  Section 6.2

Similarly, it seems that using "conformant" in place of "honest"
would be more consistent with the rest of the text, at the very
end of the last paragraph of Section 6.2.

(1c)  Section 6.2.1

The text in the box in Figure 3 has been modified to adopt the
term "compliant".
Hence it would be reasonable to change the figure cation as well.
For brevity and clearness, I suggest to change it as follows:

      Figure 3: A receiver reacting honestly to a probabilistic test
---
      Figure 3: Compliant receiver reaction to a probabilistic test

The instances of "dishonest" and "honestly" in the paragraph below
Figure 3 arguably still make sense in the stated setup.

(1d)  Sections 6.2.2, 6.2.3, and 6.2.5

This IMHO also is true for "honestly" in the first paragraph of
Section 6.2.2 and the instances "dishonest" in the first paragraph
(2x) and the second paragraph (1x) of Section 6.2.3.
The "cheat" at the latter place also seems acceptable.

Yet, this arguably does not apply to the "honest" in the last text
box in Figure 4, where I'd prefer "conformant".

The "dishonest" in the 8th bullet in Section 6.2.5 arguably is
acceptable, but might be replaced by "non-conformant" as well,
whereas the "dishonest" in the last bullet looks good to me.

(1e)  Section 6.3.2

The two instances of "dishonest" and the subsequent "honest"
in Section also make sense in that re-worded context.

(1f)  Section 6.4

I recommend changing "dishonest" to "non-conformant" in the first
line of Section 6.4, as the sender can only deduce from the test
that the receiver behaves in a non-conformant way, not the possible
rationale behind this behavior, which the reader might well feel as
being categorized by the semantics of "dishonest".

Similar arguments also apply to the subsequent word "dishonestly"
in the same paragraph.

(1g)  Section 10

Please also reconsider the "dishonest" and "honest" (one instance
each) in Section 10.  (I'm in doubt whether I should argue against
these words in favor of "non-conformant" / "conformant" or not.)


(2)  Outdated reference

The SCTP specification has been updated recently.
RFC 2960 has been obsoleted by RFC 4960.
Please update the ref. tag "[RFC2960]" used in the second-to-last
paragraph of Section 1 and the matching entry in Section 14.2
accordingly, and re-adjust the placement of that entry according
to the collation order (by increasing RFC number).


(3)  Section 6.2.1 -- new nits

In the first paragraph of Section 6.2.1, the text has been revised,
and three new flaws introduced thereby:

-  please correct the spelling:  "trhreshold"   -->  "threshold"

-  please correct the spelling:  "significnat"  -->  "significant"

-  In the sentence,
                                                To conduct the
   probabilistic test, instead of transmitting segment N, it transmits
   N+1, N+2, etc. as shown in the figure below.

   the "it" has been orphaned by the changed amended text directly
   preceding this sentence, and I suggest to clarify the text by
   substituting "the sender" for "it".


(4)  Section 6.2.3 -- Figure 4

I already had mentioned that, IMHO, in the third text box within
Figure 4, "sender" should be replaced by "receiver".
Apparently this has been missed in the update to -02.


(5)  Segment numbers vs. TCP sequence numbers --
     and possible extensions of the tests

I already had mentioned the confusion between TCP segment numbers
(e.g., "N") in the text, and TCP sequence numbers counting the
cumulative bytes in these segments (and certain specific protocol
events as well), and you have corrected that issue in the single
instance I had pointed to explicitly.

Unfortunately, when reading the text again, and with that change
in mind, it now became apparent to me that the same issue permeates
the text.  Clarification/correction is needed by also changing the
wording in the places of the draft listed below.
I also have included further ramifications of this issue, and an
ensuing potential enhancement for the tests.

(5a)  Section 6.2.1

At the end of the first paragraph, the draft says:

                                                 Once it has transmitted
   N+D it can transmit segment N. The sender needs to record the
   sequence number, N as well as the displacement, D.

It would perhaps be better to say:
                                                 Once it has transmitted
   N+D it can transmit segment N.  The sender needs to record the
   sequence number corresponding to N as well as the displacement, D.

or:
                                                 Once it has transmitted
   N+D it can transmit segment N.  The sender needs to record the
   sequence number of the first octet in segment N as well as the
   displacement, D.

But apparently, that will not suffice.

Note: Due to lack of time to investigate all the details (and
   possible opportunities for optimizations in implementations),
   I only present my concerns and ideas very roughly.

I strongly suspect that it does not suffice to record the displacement
in segments (D); perhaps the sequence number of the first octet in
segment N+D needs to be recorded (or, equivalently, the sequence
number of the last octet in segment N+D-1).
Also, the 'width' of the artificial gap in the octet stream sent,
i.e. the octet size of segment N, should perhaps be recorded as well
-- assuming it might not always equal the full MSS of the connection,
as this would allow to discriminate the unusual and suspicion-raising
receiver behavior of sending 'optimistic' ACKs for some octets in the
middle of the (not yet sent) segment N.

Reconsidering this observation, I found that there might be an
opportunity to refine and amend the tests, by tightly controlling
the segment sizes sent and recording this information until receipt
of a covering ACK.  Unless the TCP_NODELAY socket option is applied
by the sending application (cf. Section 6.5.2), and if the TCP send
buffers are filled to the extent necessary to perform the test,
the TCP sender will regulargly send segments of maximum size (MSS).
Under these circumstances, reducing the segment size randomly below
MSS by a small amount and performing suitable bookkeeping thereof,
the sender would be able to identify ACKs not matching segment
boundaries.
(Such sender behavior seems to be fully compliant with the TCP
specification, as shorter segments might also be sent at any time,
based on application requests like the TCP_NODELY socket option.)
A misbehaving receiver would then have trouble to always guess the
proper expected ACK sequence numbers matching segment boundaries
if it wants to send optimistic ACKs, thus necessarily providing
further hints to the sender of its non-conforming behavior.

(5b)  Section 6.2.5

The 5th bullet says:

   o  The sequence number N of the delayed segment MUST be recorded by
      the sender as must the amount of delay D.

It should better say:

   o  The sequence number of the delayed segment N MUST be recorded by
      the sender as must the amount of delay D.

Yet this still leaves open the question which figures should be
recorded for "the amount of delay D" -- is it D, or some sequence
number corresponding to segment N+D, or both?
See the indications above.

Note: The 9th bullet already has been clarified.

The 10th bullet says:

   o  If the sender receives an acknowledgement for a segment with a
      sequence number between N and N+D inclusively it MUST treat this
      as an indication of congestion and react appropriately.

The phrase, "sequence number between N and N+D" also is imprecise
and confusing, and should be clarified.

(5c)  Section 6.3.*

In Section 6.3.*, 'M' is the segment number for the suspended segment.
Yet, the first paragraph of Section 6.3.2 says:

                     The sender can therefore state that if it receives
   an acknowledgement for a segment with a sequence number greater than
   M before it has actually sent segment M then the receiver must either
   be cheating or is very non-compliant.

Again, "sequence number greater than M" is imprecise and confusing, and
hence should be clarified.

The second bullet in Section 6.3.3 already vaguely specifies:

   o  To perform the deterministic test the sender MUST select a segment
      M at random.  The sender MUST store this segment in the buffer of
      unacknowledged data without sending it and MUST record the
      sequence number.

It remains open exactly which sequence number to record.
But note that, arguably, this saved buffer content indirectly already
comprises the *size* of segment M, the additional information needed
for the refined tests!


(6)  Section 6.5.4

The sentence there,
         vv
                                                   [...].  SCPS-TP (SCPS
   - Tranpsort Protocol) is based on TCP and is an official TCP option
   (number 20).  [...]
                                             ^^^^^              ^^^^^^

is a bit misleading, and it contains a typo.
SCPS-TP makes use of four TCP options, with option kinds 20,...,23.

I suggest to say instead:
                                                   [...].  SCPS-TP (SCPS
   - Transport Protocol) is a modular extension of TCP making use of the
   IANA registered TCP options with Option Kind 20 through 23.  Feature
   negotiation for SCPS-TP is performed via the 'SCPS Capabilities' TCP
   option (number 20).  [...]


(7)  Section 12 -- typo

Please correct the case:  "Rob sherwood"  -->  "Rob Sherwood"


(8)  Section 14.2

(8a)
Update: see item (2) above.

(8b)
I already had asked for the addition of some more detailed
bibliographic information (and/or URL) for the terse references
[Piratla], [Savage], [Sherwood], and [VU102014].
Apparently, this has been missed.
IMHO, it would put undue load on the RFC editor to have them
figure out what you presumably already have at hands.


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+



_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm