I have reviewed this document as 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.
In preparing this review, in addition to the protocol document, I have
also read the other SHIM6 WG drafts such as the Applicability Statement
and the Failure Detection document.
Since this is a review for the Transport Directorate, the interaction
between SHIM6 and the Transport layer was my primary focus.
The basic mechanics are laid out in the protocol document, and
the ability for applications (and transports) to avoid or choose
use of SHIM6 is described in the API document. The Failure Detection
document describes the reachability detection algorithms.
Overall, I think that the document could do a better job of describing
the interaction of SHIM6 with the transport layer. While SHIM6 layering
is clearly explained, in several places within SHIM6 WG documents
interactions are described but details or recommendations are not fully
fleshed out. The transport area has traditionally demanded a higher
level of detail with respect to algorithms (particularly relating to
parameter estimation and congestion control). Overall, I think that this
document could benefit from addition of a subsection within Section
1 devoted to SHIM6-Transport layer interaction.
Overall, the biggest issue appears to be integration of
dynamically estimated transport parameters (RTT, RTO, etc.) with
SHIM6 re-homing. The impact of SHIM6 on parameter estimation
is covered in draft-schuetz-tcpm-tcp-rlci-01 which is an informative
reference even though it is "recommended".
Here are the issues that I noted within the document set:
1. MTU discovery/MSS negotiation. This is briefly discussed in
Section 15.3 of the protocol document. As noted there, SHIM6 failover may
result in a change in MTU. Some specific recommendations might be helpful
here (such as a recommendation to use Packetization Layer Path MTU discovery).
The insertion of a Payload Extension (or common shim control
message) header may also result in an MTU change in mid-connection;
however, this seems easier to handle assuming that the transport layer
is made aware of it and can reduce the MSS accordingly.
2. Keepalive Messages. Section 5.12 refers to the Failure Detection
document (a normative reference) for the definition of the Keepalive
Message format. Although I understand that the details of Keepalive
algorithms might belong in a separate document, support for
Keepalive appears to be required, so that the message
format needs to be defined in the protocol document, and I would also
like to see a discussion of the philosophy of Failure Detection in
Section 1.
Negotiation of a static SHIM6 Keepalive timeout, is
allowed, if different from the default value. Section 4.1 of the
Failure Detection document states:
The setting of these values is also related to various parameters
in transport protocols, such as TCP keepalive interval.
However, this relationship is not explored. The TCP keepalive interval
is generally kept quite large, partly out of a desire not to tear down
idle TCP connections due to a transient failure. The SHIM6 keepalive
interval during idle is not defined in the Failure Detection document,
but my impression was that it could be much shorter and this would
seem to collide with the philosophy of TCP keepalives. So I'm not clear
what the above sentence means.
3. Interactions with SCTP. The applicability statement raises some
potential issues:
However, since SCTP and shim6 both aim to exchange addressing
information between hosts in order to meet the same general goal, it
is possible that their simultaneous use might result in unexpected
behaviour, e.g. due to race conditions..... It is
recommended that shim6 is not used for SCTP sessions, and that path
maintenance is provided solely by SCTP.
The API document provides details on how SCTP can request that SHIM6
not be used with it. However, the protocol document does not discuss
this issue, which could be handled in the transport interactions section.
Given that SHIM6 is not of much use for SCTP, I wondered whether SHIM6
would bring equivalent functionality to TCP. Comparing the reachability
detection algorithms described in the Failure Detection document with the
corresponding SCTP algorithms described in RFC 4960 Section 8, the
answer appears to be "no". The SCTP algorithms make extensive use
of transport layer information such as retransmission counts, which
the SHIM6 Failure Detection document seems to assume will be unavailable.
As described later on, it would appear to me that Failure Detection
and the Transport layer need to be closely integrated to be effective;
this lead me to wonder whether this represents a potential architectural
flaw.
4. Use of DNS SRV RRs. Section 1.2 states:
The protocol provides a placeholder, in the form of the Locator
Preferences option, which can be used by hosts to express priority
and weight values for each locator. This is intentionally made
identical to the DNS SRV [6] specification of priority and weight, so
that DNS SRV records can be used for initial contact and the shim for
failover, and they can use the same way to describe the preferences.
However, Appendix A states:
o Potentially recommend that more application protocols use DNS SRV
records to allow a site some influence on load spreading for the
initial contact (before the Shim6 context establishment) as well
as for traffic which does not use the shim.
Thus, Appendix A recognizes that DNS SRV RR usage is not common today
and that changes to applications would be necessary to make full use
of this feature. Is this really something that we want to recommend
within the protocol document?
5. Interactions with lower layer indications. Section 4 of the protocol
document states:
o In addition to failures detected based on end-to-end observations,
one endpoint might know for certain that one or more of its
locators is not working. For instance, the network interface
might have failed or gone down (at layer 2), or an IPv6 address
might have become deprecated or invalid. In such cases the host
can signal its peer that this address is no longer recommended to
try. This triggers something similar to a failure handling and a
new working locator pair must be found.
In general, it would not be desirable for SHIM6 to initiate the re-homing
of a TCP connection due to a transient failure. Link layer "down"
indications or resulting address deprecations are examples of this.
SCTP (RFC 4960) contains no equivalent advice.
6. Interactions of SHIM6 with congestion control. Section 4.3 of the
Failure Detection document talks about exploration timeout values.
Exploration can be kicked off if no inbound traffic is
received within Send Timeout (default = 10 seconds).
The first observation is that the Send Timeout should probably depend
on the RTO estimate, as it does in SCTP. Otherwise we could have a
network with a high RTO and SHIM6 exploration could commence after RTO is
backed off only a few times. This would be undesirable from a congestion
control point of view.
The suggested value of the Initial Probe Timeout (500ms)
is less than RTOmin and 4 probes can be sent before initiating
exponential backoff. This seems like it could violate "conservation
of packets". Why doesn't exponential backoff begin immediately?
Instead of a static default Initial Probe Timeout value, might it
make sense to base this on RTO estimates? Again, in SCTP these issues
are handled due to integration with the transport layer.
While I realize that the Failure Detection document is separate from
the protocol specification and that this comment only relates to the
Failure Detection document, the protocol has a normative dependency
on Failure Detection, and there seems to be an architectural issue here
that relates to both documents.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf