I would like to point out a couple things that may affect how you understand things and how your argument with your friend goes.
You captured this traffic while watching youtube, but these are DNS queries (as you are of course, already aware), so this is _not_ streaming video traffic you are looking at. It will be very difficult for you to capture and understand any real streaming video traffic from youtube, because youtube is a web-based application, and will only ever generate HTTP(S) traffic, which is likely going to be TCP (unless its HTTP/3.0 or SPDY or QUIC, or something like that, but that still negates the supposed benefits of UDP for streaming video). Youtube does _not_ use UDP for streaming video, it can't, because it is limited by what your browser will allow it to do, and browsers do not let web applications initiate UDP-based communication (they can basically only do XHR requests). So TCP has a huge advantage over UDP for all web-based applications, even if its streaming video, because UDP simply isn't available to web-based applications. Youtube probably uses something like DASH or RTSP for delivering streaming video, which is basically just a text file filled with links to smaller segments of the video you are watching, so that the video player can download the parts needed to play the parts of the video near wherever you are in that video (so if you skip ahead, it won't need to download everything before that to play). This all happens over HTTP, so there's no UDP involved.
Youtube does, however, handle streaming quality issues like low-bandwidth and dropped packets (which are the supposed benefits of UDP for streaming), using an arguably better method than UDP would. Youtube monitors how fast the data has been delivered to your browser (on the client-side), and if it detects that you are not receiving the video streams fast enough for continuous playback, it will switch to a different DASH manifest that contains a lower quality version of the same video. As a result, instead of dropping frames of the video as UDP streaming would, which could cause noticeable problems if you miss i-frames, it just drops to a lower resolution. So for youtube specifically, there really is _no_ benefit to switching to UDP-based streams (nor is it even an option).
Also, it's probably never plain HTTP, it's probably always HTTPS. Which is why I say you will never see anything discernable in your packet capture, because it will be encrypted, you will only ever see the TLS "hello" exchange, and after that it will all be encrypted. It is possible to extract encryption keys from your browser and decrypt, but that's really not worth your time. If you are interested in the contents of the video stream, you can just download the video separately (FFMPEG has options to download DASH videos from a DASH URL).
Finally, I don't think you are really seeing "bad checksums" in your tcpdump. I do not know Ubuntu at all, but I assume that it uses some sort of local DNS cache. Note that your packets have a source and destination of localhost, so I think you are looking at DNS cache traffic over your loopback interface. Your loopback interface probably doesn't bother generating proper checksums, since it never actually goes through a real NIC (the NIC is usually responsible for generating and checking checksums), so you don't want to waste valuable CPU time generating and checking checksums when the data isn't even getting transmitted over a wire. These packets will not be dropped, they are circumventing the normal checksum process completely.
If you are interested in doing another capture, I would recommend you set your DNS resolver to avoid caching (remove 127.0.0.1 from /etc/resolv.conf), and also exclude the lo interface from your capture.
OR
You can also press ctrl+shift+c in your browser, then switch to the "network" tab of the sidebar that pops up, and then refresh the page. This won't give you a capture file like tcpdump does, but it will allow you to see and examine all the HTTP(s) traffic for that session, including content, which is probably what you wanted to do in the first place.
Regards,
Philip Rushik
localhost.46633 > localhost.domain: [bad udp cksum 0xfe90 -> 0x1013!] 32170+ [1au] A? rr2---sn-bvvbax-2iae.googlevideo.com. ar: . OPT UDPsize=1200 (65)
localhost.domain > localhost.46633: [bad udp cksum 0xfe90 -> 0x64b5!] 32170 ServFail* q: A? rr2---sn-bvvbax-2iae.googlevideo.com. 0/0/1 ar: . OPT UDPsize=65494 (65)
localhost.46633 > localhost.domain: [bad udp cksum 0xfe90 -> 0x76f4!] 5806+ [1au] AAAA? rr2---sn-bvvbax-2iae.googlevideo.com. ar: . OPT UDPsize=1200 (65)
localhost.domain > localhost.46633: [bad udp cksum 0xfe90 -> 0xcb96!] 5806 ServFail* q: AAAA? rr2---sn-bvvbax-2iae.googlevideo.com. 0/0/1 ar: . OPT UDPsize=65494 (65)
localhost.44911 > localhost.domain: [bad udp cksum 0xfe90 -> 0x3214!] 25187+ [1au] A? rr2---sn-bvvbax-2iae.googlevideo.com. ar: . OPT UDPsize=1200 (65)
I had a discussion with a friend of mine about unusual UDP traffic I have seen, and my friend argues that UDP is standard for streaming video today, but when I watch Youtube and run tcpdump, you can see that there are bad packets.
I want to know why UDP is superior for streaming video, because my understanding is that bad packets like this are dropped if they are UDP. Is this not the case? Can someone please clarify this? I got this output from running
"tcpdump -vvfA" while watching Youtube on an Ubuntu 22.04 laptop