Re: Comment on RFC 1981-Path MTU Discovery for IPV6
Referring to item 5.3, we think that the timestamp value need not be set to Reserved. The text in question is a suggestion, not a requirement. The use of a Reserved timestamp value is just one possible implementation of PMTU aging. Other implementations are also possible, as you have seen. FYI this text was taken from RFC 1191. - Jack IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Comment on RFC 1981-Path MTU Discovery for IPV6
Hi, Your suggestion is very much appreciated where you proposed to not to initialize timestamp to 'reserved'. But the problem here is that the timestamp should be initialize to a certain value. Otherwise the timestamp value is set to null. How would you propose to set the timestamp value? Is there any default value to the timestamp to indicate that the PMTU is equal to the MTU of the 1st hop link? Santiago, System Engineer -- Original Message -- From: Liu xiao lian [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], 'vasuki ponnusamy' [EMAIL PROTECTED] Subject: Comment on RFC 1981-Path MTU Discovery for IPV6 Date: Sat, 7 Sep 2002 23:26:37 +0800 Referring to item 5.3, we think that the timestamp value need not be set to Reserved. This is because we can just use the timestamp and the current time to determine that the PMTU has expired. For example, before sending out a packet, the timer-based procedure should check whether the PMTU to be used has expired based on the cached timestamp and current time. If it has expired indeed, then there are no packets should be sent out using this PMTU. The PMTU value should be reset to the MTU value of the first hop and the PMTU discovery should be restarted. We think the Reserved value can be removed to make the process of detemining the stale PMTUs less complicated. We welcome suggestions and comments. XiaoLian LIU Computer Science School USM 11800 Pulau Penang Malaysia Dreaming of a Swiss Account? Get it here: http://freemail.swissinfo.org IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Comment on RFC 1981-Path MTU Discovery for IPV6
Title: Comment on RFC 1981-Path MTU Discovery for IPV6 Referring to item 5.3, we think that the timestamp value need not be set to Reserved. This is because we can just use the timestamp and the current time to determine that the PMTU has expired. For example, before sending out a packet, the timer-based procedure should check whether the PMTU to be used has expired based on the cached timestamp and current time. If it has expired indeed, then there are no packets should be sent out using this PMTU. The PMTU value should be reset to the MTU value of the first hop and the PMTU discovery should be restarted. We think the Reserved value can be removed to make the process of detemining the stale PMTUs less complicated. We welcome suggestions and comments. XiaoLian LIU Computer Science School USM 11800 Pulau Penang Malaysia
Comment on RFC 1981 - Path MTU Discovery for IPv6
Referring to item 5.3, we think that the timestamp value need not be set to Reserved. This is because we can just use the timestamp and the current time to determine that the PMTU has expired. For example, before sending out a packet, the timer-based procedure should check if the PMTU to be used has expired based on the cached timestamp and the current time. If it has indeed expired, then no packets should be sent out using this PMTU. The PMTU value should be reset to the MTU value of the first hop and the PMTU discovery should be restarted. We think the Reserved value can be removed to make the process of detemining the stale PMTUs less complicated. We welcome suggestions and comments. Lim Min Min Universiti Sains Malaysia IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
