Hi, all,
I've reviewed this document as a part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to allow
them to address any issues raised. The authors should consider this
review together with any other last-call comments they receive. Please
always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or forward this review.
The document describes a protocol that is designed to use a TCP or SCTP
transport. The use of TCP is application-limited and a negotiation
mechanism is provided that helps select whether TCP or SCTP should be used.
The note below includes transport issues, as well as additional comments
that I hope are also useful.
I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.
Gorry
-----
Overall this document seems complete and uses standard IETF transport
mechanisms that support congestion control.
Introduction: Recommend to specify the IANA-assigned port.
Since this specifies a protocol that runs over a specific IANA-allocated
port it would be good if the port number was mentioned in the
Introduction. This may confirm that this is the correct document to read
to find out about what happens when port 8471 is used (e.g. someone
interpreting IPFIX or building a NAT, Firewall, etc).
Section 4 (and others, including section 7): AF for transport.
I understand there is a rule to prefer SCTP over TCP when both
transports are available. This seems OK.
Various sections refer to the support for multiple address families
(IPv4, IPv6) and I understand that the PORT information for an AF does
need not to be carried over a transport connection using the same AF.
What I do not yet understand is how PORT knows whether to use an IPv4
transport for IPv6 or to use an IPv6 transport for IPv6. I'd like this
to be clear, so that I can understand what happens when TCP is available
over Ipv4 and SCTP only over IPv6 and similar combinations.
Section 4.2: TCP keep-alive.
SCTP heartbeat is described.
I understand PORT also includes an optional keep-alive mechanism using
the transport service.
TCP also contains an optional keep-alive mechanism. This should be
mentioned. Is TCP keep-alive recommended for PORT or does the protocol
recommend a keep-alive at the PORT layer?
Section 4.2: TCP Reset
The present text says that the TCP connection will be reset "after a few
reties". This does not seem clear. A lack of acknowledgement for a sent
data segment will result in the underlying TCP tansport retransmitting
after the Retransmission Time Out (RTO). Furthermore this would cause
the RTO to be doubled with each retransmission, until the RTO exceeds
the maximum value when the connection will be reset, this is typically
many 10s of seconds later.
Section 5: Unexpected corruption of the stream
It is good to see the service using the transport, in this case PORT
verifies the integrity of the transported data. The recommendation seems
to be that PORT skips any unknown data. While this may be good for
interoperability between different flavours of the protocol, it is not
good in terms of robustness, which could be an issue for long-lived
connections.
I suggest that if such errors occur they should be made visible, so that
operators are aware that there are either PORT protocol issues or
transport issues. That way a high count of such errors would alert a
possible underlying problem.
Could a single error in the transport result in loss of farming? I
suspect so. I think it should be considered whether it be wise to close
the connection (and reopen a new transport connection) after a repeated
number of such errors.
Section 9: ?
The opening para concludes:
/This the case even when the connection is down./
- I can see this case needs to be mentioned, but I am not sure from this
text what exactly I am to understand.
Section 11.4
This section describes critical and non-critical options. I could not
find guidance for IANA on how to now whether a new option should be
classified as one or the other.
---
There are two general observations about this usage of TCP, I leave it
to the TSV ADs to decide if any of these topics should be discussed further:
1) As I understand the protocol, it is application-limited, in that it
will not usually use the entire TCP congestion window, but rather sends
"occasional" small messages under the control of PORT. It seems
important that such use does not grow an unbounded cwnd and then emit
large bursts of data into the path when the application produces bursts
of data that exceed a few MSS. It may be wise to consider a TCP stack
that includes rate-limiting or burst-limiting. RFC 3645 (EXP) may also
help in this case.
2) Since PORT may generate one or two segments of data per interval, TCP
retransmission may be slow following loss, since there may not be
sufficient to trigger fats retransmission using DupAcks. Limited
transmit (RFC 3042, STD) may help in this case.
---
Editorial/General comments:
Section 6: Use of keywords
The opening para contains two statements that could need to be RFC 2119
keywords:
/This is done for all PORT joins and PRUNES/ is this a MUST?
/It may be done for..? is this a MAY?
Page 6, section 2
/PORT capable/PORT-capable/
page 13, section 4.2
/until you actually try to send/until the PIM PORT module then tries to
send/
Section 10: ?
This section describes security threats. Please could the editors
identify whether these are on-path attacks or off-path attacks.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf