netdev - RE: [PATCHv2 net-next 00/14] sctp: implement RFC8899: Packetization Layer Path MTU Discovery for SCTP transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8328f935ec4f488e8d95486a7564aec0@AcuMS.aculab.com>
Date:   Wed, 23 Jun 2021 09:50:25 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Xin Long' <lucien.xin@...il.com>
CC:     network dev <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "Marcelo Ricardo Leitner" <marcelo.leitner@...il.com>,
        "linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>
Subject: RE: [PATCHv2 net-next 00/14] sctp: implement RFC8899: Packetization
 Layer Path MTU Discovery for SCTP transport

From: Xin Long
> Sent: 23 June 2021 04:49
...
> [103] pl_send: PLPMTUD: state: 1, size: 1200, high: 0 <--[a]
> [103] pl_recv: PLPMTUD: state: 1, size: 1200, high: 0
...
> [103] pl_send: PLPMTUD: state: 2, size: 1456, high: 0
> [103] pl_recv: PLPMTUD: state: 2, size: 1456, high: 0  <--[b]
> [103] pl_send: PLPMTUD: state: 2, size: 1488, high: 0
> [108] pl_send: PLPMTUD: state: 2, size: 1488, high: 0
> [113] pl_send: PLPMTUD: state: 2, size: 1488, high: 0
> [118] pl_send: PLPMTUD: state: 2, size: 1488, high: 0
> [118] pl_recv: PLPMTUD: state: 2, size: 1456, high: 1488 <---[c]
> [118] pl_send: PLPMTUD: state: 2, size: 1460, high: 1488
> [118] pl_recv: PLPMTUD: state: 2, size: 1460, high: 1488 <--- [d]
> [118] pl_send: PLPMTUD: state: 2, size: 1464, high: 1488
> [124] pl_send: PLPMTUD: state: 2, size: 1464, high: 1488
> [129] pl_send: PLPMTUD: state: 2, size: 1464, high: 1488
> [134] pl_send: PLPMTUD: state: 2, size: 1464, high: 1488
> [134] pl_recv: PLPMTUD: state: 2, size: 1460, high: 1464 <-- around
> 30s "search complete from 1200 bytes"
> [287] pl_send: PLPMTUD: state: 3, size: 1460, high: 0
> [287] pl_recv: PLPMTUD: state: 3, size: 1460, high: 0
> [287] pl_send: PLPMTUD: state: 2, size: 1464, high: 0 <-- [aa]
> [292] pl_send: PLPMTUD: state: 2, size: 1464, high: 0
> [298] pl_send: PLPMTUD: state: 2, size: 1464, high: 0
> [303] pl_send: PLPMTUD: state: 2, size: 1464, high: 0
> [303] pl_recv: PLPMTUD: state: 2, size: 1460, high: 1464  <--[bb]  <--
> around 15s "re-search complete from current pmtu"
> 
> So since no interval to send the next probe when the ACK is received
> for the last one,
> it won't take much time from [a] to [b], and [c] to [d],
> and there are at most 2 failures to find the right pmtu, each failure
> takes 5s * 3 = 15s.
> 
> when it goes back to search from search complete after a long timeout,
> it will take only 1 failure to get the right pmtu from [aa] to [bb].

What mtu is being used during the 'failures' ?
I hope it is the last working one.

Also, what actually happen if the network route changes from
one that supports 1460 bytes to one that only supports 1200
and where ICMP errors are not generated?

The first protocol retry is (probably) after 2 seconds.
But it will use the 1460 byte mtu and fail again.

Notwithstanding the standards, what pmtu actually exist
'in the wild' for normal networks?
Are there actually any others apart from 'full sized ethernet'
and 'PPPoE'?
So would it actually better to send two probes one for
each of those two sizes and see which ones respond?

(I'm not sure we ever manage to send full length packets.
Our data is M3UA (mostly SMS) and sent with Nagle disabled.
So even the customers sending 1000s of SMS/sec are unlikely
to fill packets.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)