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

<toby.moncaster@bt.com> Fri, 16 November 2007 09:38 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxeH-0007IW-6K; Fri, 16 Nov 2007 04:38:05 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IsxeF-0007EP-Si for tcpm-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:38:03 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxeF-0007EH-J3 for tcpm@ietf.org; Fri, 16 Nov 2007 04:38:03 -0500
Received: from smtp2.smtp.bt.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsxeB-00067w-2J for tcpm@ietf.org; Fri, 16 Nov 2007 04:38:03 -0500
Received: from E03MVZ4-UKDY.domain1.systemhost.net ([]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 09:37:58 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 16 Nov 2007 09:37:45 -0000
Message-ID: <BAB4DC0CD5148948A86BD047A85CE2A7043BEFCF@E03MVZ4-UKDY.domain1.systemhost.net>
In-Reply-To: <200711121137.MAA06290@TR-Sys.de>
Thread-Topic: draft-moncaster-tcpm-rcv-cheat-02
Thread-Index: AcglIJiuKa7J8A1xRO6oQCueAXWn5QDEizTQ
From: <toby.moncaster@bt.com>
To: <ah@tr-sys.de>, <bob.briscoe@bt.com>, <arnaud.jacquet@bt.com>
X-OriginalArrivalTime: 16 Nov 2007 09:37:58.0202 (UTC) FILETIME=[5F47F1A0:01C82834]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636
Cc: tcpm@ietf.org
Subject: [tcpm] RE: draft-moncaster-tcpm-rcv-cheat-02
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Hi Alfred,

Many thanks for sending these comments. We are currently going through them adding them to the draft for the next version. In particular we will be sure to clarify the confusion between segment and sequence numbers.

We originally did give some thought to altering the segment sizes as part of the test. This was identified by Rob Sherwood in the extended version of "Misbehaving TCP Receivers Can Cause Internet-Wide Congestion Collapse" <http://www.cs.umd.edu/~capveg/optack/optack-extended.pdf>.

We originally rejected this solution because the TCP protocol allows the receiver to cumulatively acknowledge large chunks of data (though usually this is limited to 2xMSS per ACK). We felt this meant that altering the segment sizes didn't give a sure enough test. However your suggestion of combining this behaviour with segment reordering does at first glance seem to be quite powerful. The presence of an out-of-order segment should trigger an immediate ACK even if delayed ACKs are being used. We will look into this in detail for the next version of the draft.


Toby Moncaster, <toby.moncaster@bt.com> Networks Research Centre, BT Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473 648734 

-----Original Message-----
From: Alfred HÎnes [mailto:ah@tr-sys.de] 
Sent: 12 November 2007 11:38
To: Moncaster,T,Toby,CXR9 R; Briscoe,RJ,Bob,CXR9 R; Jacquet,A,Arnaud,CXR9 R
Cc: tcpm@ietf.org
Subject: draft-moncaster-tcpm-rcv-cheat-02

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.

                                                 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,
                                                   [...].  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

Update: see item (2) above.

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,


| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |

tcpm mailing list