Subject: question regarding the implementation of PMTU discovery

From: <[email-masked]>
Date: Mon, 25 Nov 2002 13:55:42 +0800

Hi, 

I have a question regarding the implementation of PMTU discovery in SCTP layer.

In RFC 1191, it said that in IP layer, PMTU works by using the Donot fragment (DF) bit in the IP header, when the sender receive an ICMP Destination Unreachable messages with a code meaning "fragementation needed and DF set". 

RFC 1981 mentioned that, for TCP, a simple implementation could ask the IP layer for the value of PMTU each time it created a new segment, but this seems inefficient.

While  I remember La Monte had told me that may use heartbeat to realize PMTU discovery, does that mean sending 
heartbeat with DF bit set in IP header to discover the size of PMTU?

Thanks!

Hui Huang

---

From: <[email-masked]>
Date: Mon, 25 Nov 2002 16:47:24 +0200

Hi all!

	See my comments inline...

> -----Original Message-----
> From: ext [mailto:[email-masked]]
> Sent: 25. November 2002 7:56
> To: [email-masked];
> [email-masked]; [email-masked]
> Subject: question regarding the implementation of PMTU discovery
> 
> 
> Hi, 
> 
> In RFC 1191, it said that in IP layer, PMTU works by using 
> the Donot fragment (DF) bit in the IP header, when the sender 
> receive an ICMP Destination Unreachable messages with a code 
> meaning "fragementation needed and DF set". 
> 
> RFC 1981 mentioned that, for TCP, a simple implementation 
> could ask the IP layer for the value of PMTU each time it 
> created a new segment, but this seems inefficient.
> 
> While  I remember La Monte had told me that may use heartbeat 
> to realize PMTU discovery, does that mean sending 

	This is something I have done mostly since the beginning of SCTP... When I want to test one specific PMTU, what I do is just sending a HB to that address. As the HB doesn't have any structure, you can just fill it with 0s up to the MTU you want to test (taking into account all the headers). Of course, I sent that HEARTBEAT in a single packet and set the DF bit (if I'm using IPv4)...

	Then, you have three options:

	a) You receive the HEARTBEAT ACK: That means that the MTU is at least the one tested, and at the same time you also know that the address is working.
	b) You receive an ICMP packet: The MTU tested is too big. The address might or might not be working.
	c) You don't receive anything: Either the packet was lost at some point of the network, or the MTU was so big and a router in between simply discarded it (or the ICMP packet was lost), or the address is down (or something else?).

	In any case, I find the use of HB very helpful because:

	a) It is really simply to do it.
	b) At the same time you test the MTU you can test the RTO and stuff (however, the b case would be the normal one, I think).
	c) You can test exactly the size you want. In TCP it might be easy to do it using the "traditional" way, as it doesn't have any message boundaries. However, in SCTP, this is a little bit more difficult, and you might fragment user messages so the whole packet has the right shape...
	d) And which is more important, you don't increase the MTU beforehand, so it is not likely that you will lose packets. With the "traditional" way of PMTU discovery, you will normally lose some packets, and then you have to code some mechanism that realizes that those loses are due to a big MTU rather than because the peer is down (matching ICMPs and sent SCTP packets or something else).

	As far as I know, many of us use this way of measuring the PMTU. So many, that I think it might be a good idea to even write an Internet Draft relating this. If somebody is interested about this, I would like to take part in it...

	BR Iván Arias Rodríguez

---

From: <[email-masked]>
Date: Tue, 26 Nov 2002 09:42:33 +0800

Hi, Ivan,

Thanks, several more questions:

1. We should send the different sized HBs within one HB interval, is that right?
2. Currently HB can be used to test the reachability of the path of association, if suppose an HB ack for a large sized HB  is not received, that may due to the too big MTU size, so we should not increase the error count of the path.

Best regards,
Hui Huang

>From: Arias-Rodriguez Ivan (NRC/Helsinki) 
>Sent: 25 November, 2002 22:47
>To: Huang Hui (Nokia-RD/Beijing); [email-masked];
>Subject: RE: question regarding the implementation of PMTU discovery
>
>
>	Hi all!
>
>	This is something I have done mostly since the 
>beginning of SCTP... When I want to test one specific PMTU, 
>what I do is just sending a HB to that address. As the HB 
>doesn't have any structure, you can just fill it with 0s up to 
>the MTU you want to test (taking into account all the 
>headers). Of course, I sent that HEARTBEAT in a single packet 
>and set the DF bit (if I'm using IPv4)...
>
>	a) You receive the HEARTBEAT ACK: That means that the 
>MTU is at least the one tested, and at the same time you also 
>know that the address is working.
>	b) You receive an ICMP packet: The MTU tested is too 
>big. The address might or might not be working.
>	c) You don't receive anything: Either the packet was 
>lost at some point of the network, or the MTU was so big and a 
>router in between simply discarded it (or the ICMP packet was 
>lost), or the address is down (or something else?).
>
>	b) At the same time you test the MTU you can test the 
>RTO and stuff (however, the b case would be the normal one, I think).
>	c) You can test exactly the size you want. In TCP it 
>might be easy to do it using the "traditional" way, as it 
>doesn't have any message boundaries. However, in SCTP, this is 
>a little bit more difficult, and you might fragment user 
>messages so the whole packet has the right shape...
>	d) And which is more important, you don't increase the 
>MTU beforehand, so it is not likely that you will lose 
>packets. With the "traditional" way of PMTU discovery, you 
>will normally lose some packets, and then you have to code 
>some mechanism that realizes that those loses are due to a big 
>MTU rather than because the peer is down (matching ICMPs and 
>sent SCTP packets or something else).
>
>	As far as I know, many of us use this way of measuring 
>the PMTU. So many, that I think it might be a good idea to 
>even write an Internet Draft relating this. If somebody is 
>interested about this, I would like to take part in it...
>
>	BR Iván Arias Rodríguez
>
>> Thanks!
>> 
>> Hui Huang
>> 
>> 
>> 
>

---

From: <[email-masked]>
Date: Wed, 27 Nov 2002 01:37:21 +0200

Hi Hui Huang!

> Sent: 26. November 2002 3:43
> To: Arias-Rodriguez Ivan (NRC/Helsinki); [email-masked];

	Well... This is something completely implementation dependent, so I guess that you can do mostly however you want, as far as you don't go against the specification (or not that much).

	As the MTU discovery RFC says that you should wait 10 minutes after the previous test if that test was unsuccessful (which is I guess, the most common case), I think that it doesn't matter that much... I think you can forget about the normal HB interval and stuff, since you are not really going to add much traffic to the network.

	In fact, what I do (that I doubt that it is really the right option), is that at the very beginning of the association I set the MTU to 576 and then I send HBs to test up to my own MTU (following the plateaus in RFC 1191, and sending a new HB with a bigger size right after receiving the HB ACK). When either I receive the HB ACK of the HB sent with the size of my own MTU or the HB ACK is not received, I stop this mechanism and set the MTU to the value of the size of the last HB ACK received. Then, I send new HBs after 2 or 10 minutes if the last prove was successful or unsuccessful... All this is done per address...

	So, after the initial check of the MTU, I have an independent timer per address, that I set to 10 minutes after sending a "prove HB". If I don't receive the HB ACK, that timer expires and I will send another "prove HB" after that time. If I receive the HB ACK, I set the MTU to the new value and I reset the timer to 2 minutes, and after that time I will make another prove... So I use the recommended time values in RFC 1191...

> 2. Currently HB can be used to test the reachability of the 
> path of association, if suppose an HB ack for a large sized 
> HB  is not received, that may due to the too big MTU size, so 
> we should not increase the error count of the path.

	Well, as said before, this is implementation dependent... What I do personally, is not increasing the error counter if the HB ACK is received, but I do clear it if I receive the HB ACK.

	What other people think about this? What other people do?

	Thanks!

	BR Iván Arias Rodríguez