TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
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
Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
On 22 nov 2007, at 17:17, Bernard Aboba wrote: 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. Shim6 REAP keepalives aren't sent when a shim6 context is idle. The REAP protocol assumes that traffic must always be bidirectional, so when there has been outgoing traffic but no incoming traffic, there must be a failure. Keepalives exist to accommodate the cases where there is legitimately only incoming traffic but no return traffic. When traffic is flowing in both directions or when there is no traffic, there is no need to send keeplives. 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. Right. Shim6 must work for all kinds of communication. However, it would be good to make use of transport protocol knowledge when available. You feel there are missed opportunities in this area? 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. The trouble is, how do you know a problem is transient? About address deprecation: I do seem to remember a discussion where the conclusion was that deprecation is no reason to stop using an address just because it's deprecated. Telling the other end that an address should no longer be used when it's deprecated would have that effect, so if the proto document mandates that, that could be problematic. (One scenario is a router that no longer sends RAs but still continues to route, it would be possible to use the addresses after they've become deprecated until they become invalid in this case.) 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. We need the timeout to be somewhat long to accommodate the case where a host receives a packet, then does processing and finally sends an answer. However, it also needs to be fairly short so that we have time to repair a failure before the user, application or transport protocol give up. I don't think alignment with the transport's retransmission timeout makes sense here. 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? Then you'd either have to send the first few probes in quick succession without leaving a reasonable amount of time for responses to come back, or it would take very long for the first 5 or so probes to go out. 500 ms is still relatively aggressive as it's well below the maximum observed RTTs on the internet. Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Fwd: Africa and IPv6
hello everybody, a few days before someone posted this http:// wirelessafrica.meraka.org.za/wiki/index.php/DIY_Mesh_Guide#Download its a nice and simple .pdf howto about meshnetworks , isnt this another great idea to prevent loss of copper cable and step forward with networking in africa ? Regards Marc http://www.afrinic.net/statistics/ipv6_resources.htm -- Development is when you know the answer, but not how to get there. Applied research is when you know the question, but not the answer. Pure research is when you don't know the question. web: http://www.let.de ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
When traffic is flowing in both directions or when there is no traffic, there is no need to send keeplives. That makes sense. It would be helpful for the protocol document to include this explanation in the keepalive section (and also for the Failure Detection specification to remove the reference to TCP Keepalives, since they're unrelated). 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. Right. Shim6 must work for all kinds of communication. However, it would be good to make use of transport protocol knowledge when available. You feel there are missed opportunities in this area? Yes. If the transport layer can make the information available, then it seems to me that Failure Detection could be improved, providing for TCP a better approximation of the functionality in SCTP. 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. The trouble is, how do you know a problem is transient? You don't. That's why link down indications are best ignored by both the Internet and Transport layers. About address deprecation: I do seem to remember a discussion where the conclusion was that deprecation is no reason to stop using an address just because it's deprecated. Telling the other end that an address should no longer be used when it's deprecated would have that effect, so if the proto document mandates that, that could be problematic. It is suggested not mandated. However, it's hard to see a circumstance in which this would be helpful (and it will often hurt), so I'd prefer to see the suggestion removed. (One scenario is a router that no longer sends RAs but still continues to route, it would be possible to use the addresses after they've become deprecated until they become invalid in this case.) Yes. 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. We need the timeout to be somewhat long to accommodate the case where a host receives a packet, then does processing and finally sends an answer. However, it also needs to be fairly short so that we have time to repair a failure before the user, application or transport protocol give up. I don't think alignment with the transport's retransmission timeout makes sense here. The RTO represents the best estimate of the maximum time that can expire until an ACK is expected. So while I'd agree that failover should occur prior to transport connection teardown, it is not desirable for this to occur before a minimum number of RTOs has expired. The time that this takes will depend on the RTO. For example, if the goal is to re-home after 3 timeouts, using an RTOmin of 1 second, three timeouts will take 7 seconds. However, where the RTO is much larger, 10 seconds might correspond to fewer timeouts (maybe only 2). 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? Then you'd either have to send the first few probes in quick succession without leaving a reasonable amount of time for responses to come back, or it would take very long for the first 5 or so probes to go out. 500 ms is still relatively aggressive as it's well below the maximum observed RTTs on the internet. The issue is kicking off SHIM6 exploration simultaneously with transport layer congestive backoff. While SHIM6 exploration is designed to find alternate paths, the paths could still share a bottleneck. So while transport layer congestive backoff is attempting to let packets drain from the network, SHIM6 will be injecting more packets. In these situations, aggressively sending Probes will not improve the likelihood that they will get through. With respect to 500ms being well below the maximum observed RTT on the Internet, I'd observe that RTOmin is set at 1 second. So my recommendation would be to set the minimum Initial Probe Timeout to RTOmin, and allow upwards adjustment based on the RTO estimate, if available. ___ Ietf mailing list Ietf@ietf.org
Re: [Ietf-message-headers] Re: I-DAction:draft-saintandre-header-pres-00.txt
On Nov 11, 2007, at 12:57 PM, Alexey Melnikov wrote: I also don't see any particular reason for prohibiting direct use of XMPP or SIP URIs here. There is no need in extra resolution step if an email author only supports one type of IM application. +1 (thought I am fine either way - this does resolve the concerns I had) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-cheshire-ipv4-acd-05.txt
On Fri, 16 Nov 2007, Spencer Dawkins wrote: address of the interface sending the packet. The 'sender IP address' field MUST be set to all zeroes, to avoid polluting ARP caches in other hosts on the same link in the case where the address turns out to be already in use by another host. The 'target hardware address' field is ignored and SHOULD be set to all zeroes. The 'target IP Spencer: why is this SHOULD, and not MUST? I'm not asking for a change, I'm asking for a clue. I'm suspecting the answer is some really old implementations may not do this, and that would be fine if you said it - just being clear that the SHOULD isn't a license for new implementations to say I'm special. This shouldn't even be a SHOULD because it is not required for interoperability. It certainly can't be a MUST, as it conflicts with a suggestion in the original ARP specificaion (RFC 826). Here is what RFC 826 has to say about how an ARP implementation sets the target hardware address in an ARP request that it is about to broadcast: | It does not set ar$tha to anything in particular, | because it is this value that it is trying to determine. It | could set ar$tha to the broadcast address for the hardware (all | ones in the case of the 10Mbit Ethernet) if that makes it | convenient for some aspect of the implementation. In other words, the target hardware address does not matter and can be set to any value. I am aware of implementations that follow the suggestion (which would be a MAY in 2119 parlance) to set ar$tha to the broadcast address when broadcasting an ARP request. Here is the guidance from Section 6 or RFC 2119 on the use of imperatives such as should: | Imperatives of the type defined in this memo must be used with care | and sparingly. In particular, they MUST only be used where it is | actually required for interoperation or to limit behavior which has | potential for causing harm (e.g., limiting retransmisssions) For | example, they must not be used to try to impose a particular method | on implementors where the method is not required for | interoperability. I do not see how the above SHOULD enhances interoperability or limits the potential for causing harm. Insofar as draft-cheshire-ipv4-acd-05.txt claims not to modify any protocol rules, its insistence that ar$tha should be set to zero in ARP request packets certainly looks odd to me. While I am at it, I also have an issue with the draft's Section 4, Historical Note. The first sentence reads: A widely-known, but ineffective, duplicate address detection technique called Gratuitous ARP is found in many deployed systems [Ste94]. This sentence seems to claim that the intended purpose of Gratuitous ARP was to perform duplicate address detection. That was not the case. Its purpose was to flush stale entries out of ARP caches when a station's IP address (or Ethernet address) changed. See, e.g., RFC 2002 and references therein. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [tsv-dir] Re: TSV-DIR Review of draft-ietf-shim6-protocol-09.txt
When traffic is flowing in both directions or when there is no traffic, there is no need to send keeplives. That makes sense. It would be helpful for the protocol document to include this explanation in the keepalive section (and also for the Failure Detection specification to remove the reference to TCP Keepalives, since they're unrelated). 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. Right. Shim6 must work for all kinds of communication. However, it would be good to make use of transport protocol knowledge when available. You feel there are missed opportunities in this area? Yes. If the transport layer can make the information available, then it seems to me that Failure Detection could be improved, providing for TCP a better approximation of the functionality in SCTP. 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. The trouble is, how do you know a problem is transient? You don't. That's why link down indications are best ignored by both the Internet and Transport layers. About address deprecation: I do seem to remember a discussion where the conclusion was that deprecation is no reason to stop using an address just because it's deprecated. Telling the other end that an address should no longer be used when it's deprecated would have that effect, so if the proto document mandates that, that could be problematic. It is suggested not mandated. However, it's hard to see a circumstance in which this would be helpful (and it will often hurt), so I'd prefer to see the suggestion removed. (One scenario is a router that no longer sends RAs but still continues to route, it would be possible to use the addresses after they've become deprecated until they become invalid in this case.) Yes. 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. We need the timeout to be somewhat long to accommodate the case where a host receives a packet, then does processing and finally sends an answer. However, it also needs to be fairly short so that we have time to repair a failure before the user, application or transport protocol give up. I don't think alignment with the transport's retransmission timeout makes sense here. The RTO represents the best estimate of the maximum time that can expire until an ACK is expected. So while I'd agree that failover should occur prior to transport connection teardown, it is not desirable for this to occur before a minimum number of RTOs has expired. The time that this takes will depend on the RTO. For example, if the goal is to re-home after 3 timeouts, using an RTOmin of 1 second, three timeouts will take 7 seconds. However, where the RTO is much larger, 10 seconds might correspond to fewer timeouts (maybe only 2). 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? Then you'd either have to send the first few probes in quick succession without leaving a reasonable amount of time for responses to come back, or it would take very long for the first 5 or so probes to go out. 500 ms is still relatively aggressive as it's well below the maximum observed RTTs on the internet. The issue is kicking off SHIM6 exploration simultaneously with transport layer congestive backoff. While SHIM6 exploration is designed to find alternate paths, the paths could still share a bottleneck. So while transport layer congestive backoff is attempting to let packets drain from the network, SHIM6 will be injecting more packets. In these situations, aggressively resending Probes will not improve the likelihood that they will get through. With respect to 500ms being well below the maximum observed RTT on the Internet, I'd observe that RTOmin is set at 1 second. So my recommendation would be to set the minimum Initial Probe Timeout to RTOmin, and allow upwards adjustment based on the RTO estimate, if available. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 35 messages in the last 7 days. script run at: Fri Nov 23 00:53:01 EST 2007 Messages | Bytes| Who +--++--+ 11.43% |4 | 8.67% |23062 | [EMAIL PROTECTED] 8.57% |3 | 6.27% |16667 | [EMAIL PROTECTED] 8.57% |3 | 5.64% |15003 | [EMAIL PROTECTED] 5.71% |2 | 8.00% |21259 | [EMAIL PROTECTED] 5.71% |2 | 7.76% |20632 | [EMAIL PROTECTED] 5.71% |2 | 5.47% |14547 | [EMAIL PROTECTED] 2.86% |1 | 7.96% |21174 | [EMAIL PROTECTED] 5.71% |2 | 5.09% |13537 | [EMAIL PROTECTED] 5.71% |2 | 4.37% |11617 | [EMAIL PROTECTED] 2.86% |1 | 4.91% |13054 | [EMAIL PROTECTED] 2.86% |1 | 4.04% |10732 | [EMAIL PROTECTED] 2.86% |1 | 4.01% |10665 | [EMAIL PROTECTED] 2.86% |1 | 3.31% | 8800 | [EMAIL PROTECTED] 2.86% |1 | 3.07% | 8163 | [EMAIL PROTECTED] 2.86% |1 | 2.78% | 7385 | [EMAIL PROTECTED] 2.86% |1 | 2.73% | 7254 | [EMAIL PROTECTED] 2.86% |1 | 2.50% | 6651 | [EMAIL PROTECTED] 2.86% |1 | 2.50% | 6645 | [EMAIL PROTECTED] 2.86% |1 | 2.39% | 6347 | [EMAIL PROTECTED] 2.86% |1 | 2.38% | 6325 | [EMAIL PROTECTED] 2.86% |1 | 2.17% | 5762 | [EMAIL PROTECTED] 2.86% |1 | 2.02% | 5376 | [EMAIL PROTECTED] 2.86% |1 | 1.96% | 5207 | [EMAIL PROTECTED] +--++--+ 100.00% | 35 |100.00% | 265864 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
