Date: Sat, 19 Aug 2017 11:56:12 -0500 From: "Mike Karels" <mike@karels.net> To: "Julian Elischer" <julian@freebsd.org> Cc: "Gopakumar Pillai" <gpillai@vmware.com>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, "freebsd-net@FreeBSD.org" <freebsd-net@FreeBSD.org> Subject: Re: Only last IP frag sent if ARP entry absent Message-ID: <EF9870E7-2622-4250-8897-2711C0B51692@karels.net> In-Reply-To: <f9fcad5d-1fc3-0d53-8eb1-0577df673c38@freebsd.org> References: <F9ABB88D-108D-4EF0-8962-091662F488FD@vmware.com> <43CC3432-DB42-4170-B3E7-E305561973F3@lists.zabbadoz.net> <AFD0C317-D4E2-4A9E-B6F2-CCA2B0B7464F@vmware.com> <9B1B1A12-CD9F-4A9F-B596-A2F6E5BAED1E@karels.net> <f9fcad5d-1fc3-0d53-8eb1-0577df673c38@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19 Aug 2017, at 4:00, Julian Elischer wrote: > On 18/8/17 11:33 am, Mike Karels wrote: >> Another $.02 (inline): >> >> On 17 Aug 2017, at 18:39, Gopakumar Pillai wrote: >> >>> Thank You Bjoern. Could you please point me to the RFC? >> >> I don=E2=80=99t know if there is anything more recent than RFC1122 on = this.=20 >> IIRC, it requires queuing at least one packet. Queing one packet is=20 >> what BSD has done essentially since ARP was implemented. > > This asks the question: One physical packet or one logical packet? > Gopakumar's change effectively changes the queuing from one physical=20 > packet to the logical one. > The next question becomes "how much extra work do we do to achieve=20 > this and does it affect anything else"? That isn=E2=80=99t the whole question. It=E2=80=99s one physical packet,= one=20 logical packet, or multiple frames? It makes more sense to me to support multiple frames rather than just=20 one logical packet. However, I don=E2=80=99t see a good reason to change from the current code. >>> If this is not a MUST behavior in RFC, would my fix be good? I agree=20 >>> that this would affect only ICMP/UDP traffic. >> >> People have been asking for queuing of multiple packets for years. =20 >> That is a more general change. Consider another dumb application=20 >> that starts out by sending multiple UDP packets back-to-back. =20 >> However, well-designed application protocols don=E2=80=99t experience=20 >> problems like this. I=E2=80=99ll quickly note that ping isn=E2=80=99t= an=20 >> application, but a network measuring tool. If you ask the question=20 >> =E2=80=9Cwhat happens if I start off a session with a single large pac= ket=20 >> and I don=E2=80=99t support retransmission=E2=80=9D, ping answers that= question=20 >> correctly. >> >> If badly-designed protocols get bad performance, that doesn=E2=80=99t = seem=20 >> like a bug to me, but a feature. >> >>> On 8/17/17, 2:40 PM, "Bjoern A. Zeeb"=20 >>> <bzeeb-lists@lists.zabbadoz.net> wrote: >>> >>> On 17 Aug 2017, at 21:16, Gopakumar Pillai wrote: >>> >>> > Hi FreeBSD Networking Gurus, >>> > I came across an issue with an old version of FreeBSD and=20 >>> looking at >>> > the latest FreeBSD code, seems it exists even now. I am=20 >>> assuming that >>> > this issue is not reported. >>> > >>> > Observation: >>> > When a ping was performed with larger payload than MTU, the=20 >>> first ping >>> > failed when the ARP entry was absent for that IP. >>> >>> That is because ping/ICMP has no retransmit. >>> >>> >>> > Noticed on the wire that the last IP fragment was sent for the=20 >>> first >>> > request and then the subsequent requests were fine. >>> > >>> > Root Cause: >>> > * ip_output fragments the packets and loops through the=20 >>> fragments to >>> > send them to ether_output. >>> > * ether_output does an arpresolve and if there is no=20 >>> existing ARP >>> > entry it'll return EWOULDBLOCK after sending ARP Request. >>> > * ether_output ignores the error and propagates success to=20 >>> ip_output >>> > and it continues to send the remaining fragments. >>> > * llentry keeps only one mbuf and the last fragment is=20 >>> retained when >>> > the ARP Reply comes and the fragment is sent. >>> >>> Yes, according to the spec (RFC) we are supposed to throw the=20 >>> packet >>> away entirely and simply report that to the next upper layer. =20 >>> However >>> over the years people realised that this sucks for a TCP SYN=20 >>> packet with >>> a retransmit timer and hence we store one of them. >>> >>> A large UDP packet would btw see the same behaviour to your=20 >>> ping. >>> There=E2=80=99s no guarantee any of these packets will not be dro= pped=20 >>> anywhere >>> on the network, so we can as well. >>> >>> Just my 2ct >>> >>> /bz >> >> Mike >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to=20 >> "freebsd-net-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EF9870E7-2622-4250-8897-2711C0B51692>