Path MTU discovery and retransmission

Question

I'm reading about IP at the moment and one thing I haven't been able to comprehend very well, is the retransmit situation for IP packets with DF set.

In this situation, I assume the following happens between PC's direct router/gateway agrees on MTU but not the next router in the path. So let's assume the following diagram PC -> R1 -> R2. When R2 rejects the packet because the datagram is larger than its MTU, it drops the packet and sends an ICMP message with "Packet is too big" plus the IP header.

My question is: Who is responsible for retransmitting the message? is it the previous router or the source (PC) ? and if so, how does the PC know which datagram to resend? are datagrams kept for a while in memory after they've been sent or retransmission is only feasible for tcp-ip packets?

Answer 1

If a PC receives an ICMP Fragmentation required message, the PC must resend any traffic. Normally only TCP handles retransmission (including loss from MTU issues); TCP also includes support for Path MTU discovery.

In case of non-TCP applications which are written to support PMTU discovery and retransmission, the PC could know which packets to resend because ICMP errors include the context of the packet which generated the error... this is a dump from tshark -Vi eth0 icmp... Look below MTU of next hop, it shows that this ICMP message was received in response to a UDP packet to 172.16.255.1 (with DF set), which was too large.

Internet Protocol, Src: 172.16.1.1 (172.16.1.1), Dst: 172.16.1.5 (172.16.1.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 56
    Identification: 0x6297 (25239)
    Flags: 0x00
        0.. = Reserved bit: Not Set
        .0. = Don't fragment: Not Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 255
    Protocol: ICMP (0x01)
    Header checksum: 0xfe46 [correct]
        [Good: True]
        [Bad : False]
    Source: 172.16.1.1 (172.16.1.1)
    Destination: 172.16.1.5 (172.16.1.5)
Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 4 (Fragmentation needed)
    Checksum: 0x8813 [correct]
    MTU of next hop: 1420
    Internet Protocol, Src: 172.16.1.5 (172.16.1.5), Dst: 172.16.255.1 (172.16.255.1)
        Version: 4
        Header length: 20 bytes
        Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
            0000 00.. = Differentiated Services Codepoint: Default (0x00)
            .... ..0. = ECN-Capable Transport (ECT): 0
            .... ...0 = ECN-CE: 0
        Total Length: 1500
        Identification: 0x3aff (15103)
        Flags: 0x02 (Don't Fragment)
            0.. = Reserved bit: Not Set
            .1. = Don't fragment: Set
            ..0 = More fragments: Not Set
        Fragment offset: 0
        Time to live: 1
            [Expert Info (Note/Sequence): "Time To Live" only 1]
                [Message: "Time To Live" only 1]
                [Severity level: Note]
                [Group: Sequence]
        Protocol: UDP (0x11)
        Header checksum: 0xe0ea [correct]
            [Good: True]
            [Bad : False]
        Source: 172.16.1.5 (172.16.1.5)
        Destination: 172.16.255.1 (172.16.255.1)
    User Datagram Protocol, Src Port: 60742 (60742), Dst Port: 33437 (33437)
        Source port: 60742 (60742)
        Destination port: 33437 (33437)
        Length: 1480
        Checksum: 0xf73f [unchecked, not all data available]
            [Good Checksum: False]
            [Bad Checksum: False]

Answer 2

Note: This only works for TCP. As per spec, the originator of the traffic must keep all traffic until it has been acknowledged by the receiver. If a packet is lost in transit, it can be resent. If a packet must be smaller, it can be resent.

This can be done with UDP, but it requires the application do it. (i.e. replicate TCP's reliable transport, at which point there's no reason not to use TCP.)