[dtn] Mirja Kühlewind's Discuss on draft-ietf-dtn-tcpclv4-18: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dtn-tcpclv4-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this well-written document. I have a couple of thing in the comment
section below that should be clarified. But there is one point which does not
seem correct to me and therefore I'm raising it at thee discuss level:

Sec 5.1.1:
"Both sides SHALL send a KEEPALIVE message whenever the negotiated interval
   has elapsed with no transmission of any message (KEEPALIVE or other).

   If no message (KEEPALIVE or other) has been received in a session
   after some implementation-defined time duration, then the node SHALL
   terminate the session by transmitting a SESS_TERM message (as
   described in Section 6.1) with reason code "Idle Timeout". "

It is not necessary that both endpoints send keepalives when TCP is used
underneath as data is transmitted reliably. If one end sends keepalives and
transmission fails it will close the TCP connection no matter what. Therefore
the case where no keepalive is received, can only happen if no keepalive was
send by the application, however, if the own keepalives are send successfully
it is also received and the TCP connection is alive. If this is only to test
liveness of the TCP connection, why don't you use TCP keepalives instead?

Further what happens when a keepalive fails? Should one endpoint try to
reconnect, immediately or later when new data is available?

And one more small thing:
sec 6.1:
"However, an entity MUST always send
   the contact header to its peer before sending a SESS_TERM message."
This normative requirement seems contradicting the way version failures are
handled earlier on in the doc.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) Sec 4.1:
"Therefore, the entity MUST retry the
   connection setup no earlier than some delay time from the last
   attempt."
It would be good to provide a recommended value or at least a minimum value.

2) Similar here in sec 4.1:
" If the
   passive entity does not receive a Contact Header after some
   implementation-defined time duration after TCP connection is
   established, the entity SHALL close the TCP connection."
It would be good to provide some default value or at least some more discussion
about ranges of values. In any case this value should be larger than X times
the RTT as TCP segments can get lost any might need to be transmitted. I guess
something in the order of second would be appropriate?

3) Sec 4.3:
" To prevent a flood
   of repeated connections from a misconfigured application, an entity
   MAY elect to hold an invalid connection open and idle for some time
   before ending it."
Not sure why you need to hold it open...? All you need is to not accept but
ignore new connections from that peer/IP address for some time. And more
questions:
  - When kept open and you suddenly received a valid message, should you
  process it? - And when  you finally decide to close the connection, how do
  you do that? TCP RST, or FIN? - Do you send (TCP) keepalives?

4) Also 4.3:
"   The first negotiation is on the TCPCL protocol version to use.  The
   active entity always sends its Contact Header first and waits for a
   response from the passive entity.  The active entity can repeatedly
   attempt different protocol versions..."
If you read on in this section it seems like the receiver always sends a
SESS_TERM if the version is not compatible. So I assume you mean the active
entity can open a TCP and try again. And I assume it should do it immediately
after the SESS_TERM is received. I believe that's what the following paragraphs
say but this part confused me a bit. So might be only an editorial issue.
Please clarify! However, if there would be any attempt to send another CH on
the same TCP connection, that could lead to ambiguity and would need to be
further specified. Also more point, the text does not specify what the
receiver's response to the CH is. The figure shows that it will also send a CH,
however, that should also be spelled out in the text!

5) sec 4.4.1:
"When present, the SNI SHALL contain the same host name
      used to establish the TCP connection."
Not sure what this means... how do you use an host name in an TCP connection?
Do you mean the same host name that has been used in name resolution to get the
IP address that is used to establish the TCP connection? Or something else?

6) sec 5.1.2:
What is the entity receiving the MSG_REJECT supposed to do?

7) sec 5.2.3: General question on the ACK mechanism: As you say correctly the
fact that you don't get a notification is not a TCP protocol matter but only an
interface matter. E.g. if taps would be used, this information would be
available. Was it considered to make the ACK mechanism optional, e.g. by using
a flag in the XFER_SEGMENT to request an ACK per segment? Also more questions:
 - Why are the message flags reflected?
 - Why is the Acknowledged length field needed if there needs to be one ACK
 (send in order) for each segment anyway?

8) sec 5.2.4: Can you maybe explain why the XFER_REFUSE is a message/feature of
the CL and not the BP?

9) sec 5.2.4:
"If a sender receives a XFER_REFUSE message, the sender
   MUST complete the transmission of any partially sent XFER_SEGMENT
   message.  There is no way to interrupt an individual TCPCL message
   partway through sending it."
Not sure if use of normative language is appropriate here, because I believe
what you mean is that as soon as the data/message is given to the TCP
connection, you can't call it back. That's just a fact and nothing the sender
may or can enforce. However, it could reset the TCP connection effectively but
that probably not what is desired. Please clarify or remove normative language!

10) sec 5.2.5.1: Can you further explain what the use case ifs for the Transfer
Length Extension? When do you expect the actual length to be different?

11) sec 6.1:
"   After sending a SESS_TERM message, an entity MAY continue a possible
   in-progress transfer in either direction."
Why is this necessary? Why can the entity not just send the SESS_TERM after the
end of the transfer? Please clarify in the doc!

12) 6.1:
" When performing an unclean shutdown, a receiving node
   SHOULD acknowledge all received data segments before closing the TCP
   connection."
What do you mean here? TCP acknowledgements? If so, this should not be
normative as TCP will do that not matter what. However, you can not send any
new application data/CL ACK after a TCP FIN was sent. Please clarify!

13) sec 6.1:
"   If a session is to be terminated before a protocol message has
   completed being sent, then the node MUST NOT transmit the SESS_TERM
   message but still SHALL close the TCP connection. "
Not sure how this case is supposed to happen. When give a message to your TCP
stack it will send it. If sending fails on the TCP level, the connection will
be closed automatically. Or do I misunderstand the intended scenario here?