UDP file transfer

[H D]

What is the best way to simulate file transfer in NS-3 when the transport layer is UDP?

I thought to use UdpEchoClientHelper echoClient as the sender and UdpEchoServerHelper echoServer as the receiver, but I'm getting nonsensical results.. (Given a specific topology, when I run flows with the same data by using the above classes [udp], I get 0 lost packets but when using BulkSendHelper - TCP, I get around 13 lost packets)

[Tommaso Pecorella]

TCP will try to fill the links, UDP doesn't (it simply uses the data rate specified by the application).

Your statement "nonsensical results" is lacking context, perhaps the results are perfectly valid given your setup and scenario... which only you can analyze.

About "the best way to simulate file transfers using UDP", it depends on what's your model, but mind that BulkSend can use UDP... just check the "Protocol" attribute.

[H D]

No, I can't use BulkSend with UDP, I get this error:

msg="Using BulkSend with an incompatible socket type. BulkSend requires SOCK_STREAM or SOCK_SEQPACKET. In other words, use TCP instead of UDP."

https://github.com/simbricks/ns-3/blob/main/src/applications/model/bulk-send-application.cc#L142

[H D]

I defined the following topology (p2p link for each link):

0 - 2 [link 1]
1 - 2 [link 2]

2 - 3 [link 3]

3 - 4 [link 4]

3 - 5 [link 5]

with the following conditions on each link:

p2p.SetDeviceAttribute("DataRate", StringValue("1Mbps"));

p2p.SetDeviceAttribute("Delay", StringValue("2ms"));

And I ran the following flows:

1. from node 0 to node 4

2. from node 1 to node 5

by using UdpEchoServerHelper and UdpEchoClientHelper[MaxPackets=2048, PacketSize=586] and I get 0 lost packets...

On the other hand, when I run the flows with BulkSendHelper (TCP) [sender] [with MaxBytes 1200000]  and PacketSinkHelper [receiver] on the same topology, I get approximately 16 lost packets.

[H D]

More statistics:

with UDP:

(master)$ python3 flowmon-parse-results.py myfile.xml  
Reading XML file  . done.
FlowID: 1 (UDP 192.0.0.1/49153 --> 192.0.3.2/7)
        TX bitrate: 4.91 kbit/s
        RX bitrate: 4.91 kbit/s
        Mean Delay: 20.78 ms
        Packet Loss Ratio: 0.00 %
FlowID: 2 (UDP 192.0.1.1/49153 --> 192.0.4.2/7)
        TX bitrate: 4.91 kbit/s
        RX bitrate: 4.91 kbit/s
        Mean Delay: 25.71 ms
        Packet Loss Ratio: 0.00 %
FlowID: 3 (UDP 192.0.3.2/7 --> 192.0.0.1/49153)
        TX bitrate: 4.91 kbit/s
        RX bitrate: 4.91 kbit/s
        Mean Delay: 20.78 ms
        Packet Loss Ratio: 0.00 %
FlowID: 4 (UDP 192.0.4.2/7 --> 192.0.1.1/49153)
        TX bitrate: 4.91 kbit/s
        RX bitrate: 4.91 kbit/s
        Mean Delay: 20.78 ms
        Packet Loss Ratio: 0.00 %

  (Monitor ID: 1) Five Tuple: [Src Addr: 192.0.0.1], [Dst Addr: 192.0.3.2], [Src Port: 49153], [Dst Port: 7], [Protocol: UDP]
  Tx: [Packets = 2048] , [Bytes = 1257472]
  Rx: [Packets = 2048] , [Bytes = 1257472]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.02078
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   2048.02
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   2048
  lost Packets:   0
  Packets/Bytes Dropped by Queue Disc:   0 / 0
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0
  (Monitor ID: 2) Five Tuple: [Src Addr: 192.0.1.1], [Dst Addr: 192.0.4.2], [Src Port: 49153], [Dst Port: 7], [Protocol: UDP]
  Tx: [Packets = 2048] , [Bytes = 1257472]
  Rx: [Packets = 2048] , [Bytes = 1257472]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.02571
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   2048.03
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   2048
  lost Packets:   0
  Packets/Bytes Dropped by Queue Disc:   0 / 0
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0
  (Monitor ID: 3) Five Tuple: [Src Addr: 192.0.3.2], [Dst Addr: 192.0.0.1], [Src Port: 7], [Dst Port: 49153], [Protocol: UDP]
  Tx: [Packets = 2048] , [Bytes = 1257472]
  Rx: [Packets = 2048] , [Bytes = 1257472]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.04157
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1.02078
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   2048.04
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   2048.02
  lost Packets:   0
  Packets/Bytes Dropped by Queue Disc:   0 / 0
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0
  (Monitor ID: 4) Five Tuple: [Src Addr: 192.0.4.2], [Dst Addr: 192.0.1.1], [Src Port: 7], [Dst Port: 49153], [Protocol: UDP]
  Tx: [Packets = 2048] , [Bytes = 1257472]
  Rx: [Packets = 2048] , [Bytes = 1257472]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.0465
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1.02571
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   2048.05
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   2048.03
  lost Packets:   0
  Packets/Bytes Dropped by Queue Disc:   0 / 0
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0

with TCP:

Reading XML file  . done.
FlowID: 1 (TCP 192.0.0.1/49153 --> 192.0.3.2/7)
        TX bitrate: 501.02 kbit/s
        RX bitrate: 497.46 kbit/s
        Mean Delay: 447.86 ms
        Packet Loss Ratio: 0.71 %
FlowID: 2 (TCP 192.0.1.1/49153 --> 192.0.4.2/7)
        TX bitrate: 503.35 kbit/s
        RX bitrate: 497.92 kbit/s
        Mean Delay: 448.55 ms
        Packet Loss Ratio: 0.71 %
FlowID: 3 (TCP 192.0.3.2/7 --> 192.0.0.1/49153)
        TX bitrate: 27.02 kbit/s
        RX bitrate: 27.01 kbit/s
        Mean Delay: 7.38 ms
        Packet Loss Ratio: 0.00 %
FlowID: 4 (TCP 192.0.4.2/7 --> 192.0.1.1/49153)
        TX bitrate: 27.52 kbit/s
        RX bitrate: 27.52 kbit/s
        Mean Delay: 7.40 ms
        Packet Loss Ratio: 0.00 %

  (Monitor ID: 1) Five Tuple: [Src Addr: 192.0.0.1], [Dst Addr: 192.0.3.2], [Src Port: 49153], [Dst Port: 7], [Protocol: TCP]
  Tx: [Packets = 2258] , [Bytes = 1325996]
  Rx: [Packets = 2242] , [Bytes = 1316588]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.00739
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   22.1802
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   22.1729
  lost Packets:   16
  Packets/Bytes Dropped by Queue Disc:   16 / 9408
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0
  (Monitor ID: 2) Five Tuple: [Src Addr: 192.0.1.1], [Dst Addr: 192.0.4.2], [Src Port: 49153], [Dst Port: 7], [Protocol: TCP]
  Tx: [Packets = 2258] , [Bytes = 1325996]
  Rx: [Packets = 2242] , [Bytes = 1316588]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.00786
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   22.1613
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   22.0746
  lost Packets:   16
  Packets/Bytes Dropped by Queue Disc:   16 / 9408
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0
  (Monitor ID: 3) Five Tuple: [Src Addr: 192.0.3.2], [Dst Addr: 192.0.0.1], [Src Port: 7], [Dst Port: 49153], [Protocol: TCP]
  Tx: [Packets = 1283] , [Bytes = 71448]
  Rx: [Packets = 1283] , [Bytes = 71448]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.01478
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1.00739
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   22.1729
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   22.1652
  lost Packets:   0
  Packets/Bytes Dropped by Queue Disc:   0 / 0
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0
  (Monitor ID: 4) Five Tuple: [Src Addr: 192.0.4.2], [Dst Addr: 192.0.1.1], [Src Port: 7], [Dst Port: 49153], [Protocol: TCP]
  Tx: [Packets = 1296] , [Bytes = 72764]
  Rx: [Packets = 1296] , [Bytes = 72764]
  timeFirstRxPacket (the absolute time when the first packet in the flow was received by an end node):   1.01525
  timeFirstTxPacket (the absolute time when the first packet in the flow was transmitted):   1.00786
  timeLastRxPacket (the absolute time when the last packet in the flow was received):   22.1643
  timeLastTxPacket (the absolute time when the last packet in the flow was transmitted):   22.1569
  lost Packets:   0
  Packets/Bytes Dropped by Queue Disc:   0 / 0
  Packets/Bytes Dropped by NetDevice:   0 / 0
  Packets/Bytes Dropped because TTL-EXPIRE:   0 / 0

[Tommaso Pecorella]

Again, you're comparing an apple and a fish.

UDP: TX bitrate: 4.91 kbit/s

TCP: TX bitrate: 501.02 kbit/s

it's a HUNDRED time more.

[H D]

I have attached my code here. I don't understand what causes this difference.

You can run the simulation using:

./ns3 run scratch/my_example.cc -- --protocol=tcp

or

./ns3 run scratch/my_example.cc -- --protocol=udp

As you can see in my code, I use exactly the same topology, only once with TCP and once with UDP.

[Tommaso Pecorella]

Let's try again, and I'll try to be as clear as possible.

First, your UDP is sending data at a much lower rate than TCP - you have to modify the "Interval" attribute to compare them.

Second, BulkSend will fill ALL the TCP buffer and will try to send as many data as possible in the shortest time (UDP doesn't).

As a consequence, since TCP will have always something to send, it will try to fill the channel. As soon as it will have to throttle down the rate (normal TCP behavior) TCP might experience a drop in the output queues. This is totally normal.

TCP will **always** experience some packet losses because this is how it probes for the optimal sending rate.

UDP does NOT have a similar mechanism, so you'll never see drops due to congestion control algorithms.

Again Apples (UDP) and Fishes (TCP). You can eat both, but they're different.

[H D]

So I'm a bit confused. My goal is to compare the performance of TCP versus UDP when I'm simulating file transfer. And I expect (as we learned in class) that with UDP there will be more lost packets because it's a less reliable protocol (does not perform retransmissions) compared to TCP..

I don't want to compare apples and fishes, but rather compare the performance of TCP versus UDP.

I understand (based on your explanation) that the model I used for UDP file transfer isn't really suitable for file transfer... (right?)
If so, how can I truly achieve what I want? To simulate file transfer with UDP...

[Tommaso Pecorella]

Sorry to contradict your teacher, but the problem is in the statement "with UDP there will be more lost packets because it's a less reliable protocol". This is plainly wrong.

UDP isn't "less reliable", it is unreliable. This means that it won't try to recover lost packets, and the application (or a layer above UDP) have to implement a retransmission scheme for the lost packets. Moreover it won't try to remove duplicate packets, and the application [... as for the lost packets].

This doesn't mean that UDP will drop more packets than TCP. It can loose less or more, it's not related to the fact that it's an unreliable protocol.

Packet losses are due either to channel errors (similar between TCP and UDP) and congestions.

- TCP WILL try to reach congestion, because that's how it probes for the end-to-end available bandwidth. Hence, it WILL loose some packets (hopefully only a few).
- UDP DOES NOT probe for the end-to-end available bandwidth and the packet losses (due to congestion) are only related to the UDP sending rate. If you choose it right UDP won't loose any packet. If you choose it wrong it will drop a LOT of packets.

File transfer protocols using UDP usually implement a congestion control protocol at application level, or in a layer between the application and UDP, and this is what QUIC does.

So, no - UdpEcho isn't the right application. You'll have to use QUIC (see https://apps.nsnam.org/app/quic) or you'll have to implement a congestion control in your own application.

Of course any result will only show how "good" is the congestion control mechanism in avoiding congestion and using the bandwidth in the most optimal way, and your comparison will not about TCP and UDP. Rather it will be between that particular TCP congestion control and the one you're using on top of UDP.

Mind that I did leave out some details, like segment reordering and retransmissions, which have to be implemented on top of UDP, and the fact that it's always possible to implement similar congestion control algorithms in both cases, so the real tie-breaker will be on the overhead and the possibility to add more feedbacks on top of UDP, because you're not constrained by the TCP header fields.

Clear now?

[H D]

Thank you very much, it's clearer now.

Regarding the QUIC extension you mentioned, which application can I use with QUIC to simulate file transfer?

I tried this way:

//QUIC

    // flow1:

    int sink_port = 7;

    Address sinkAddress_node4(InetSocketAddress(ipv4_interfaces4.GetAddress(1), sink_port));

    PacketSinkHelper packetSinkHelper1("ns3::QuicSocketFactory", InetSocketAddress(Ipv4Address::GetAny(), sink_port));

    ApplicationContainer sinkApp1 = packetSinkHelper1.Install(routers.Get(4));

    sinkApp1.Start(Seconds(0));

    sinkApp1.Stop(Seconds(total_time));

    int size = 1200000;

    BulkSendHelper sender1("ns3::QuicSocketFactory", sinkAddress_node4);

    sender1.SetAttribute("MaxBytes", UintegerValue(size)); // Size in bytes

    ApplicationContainer senderApps1 = sender1.Install(routers.Get(0));

    senderApps1.Start(Seconds(1.0));

    senderApps1.Stop(Seconds(total_time));

    // flow2:

    Address sinkAddress_node5(InetSocketAddress(ipv4_interfaces5.GetAddress(1), sink_port));

    PacketSinkHelper packetSinkHelper2("ns3::QuicSocketFactory", InetSocketAddress(Ipv4Address::GetAny(), sink_port));

    ApplicationContainer sinkApp2 = packetSinkHelper2.Install(routers.Get(5));

    sinkApp2.Start(Seconds(0));

    sinkApp2.Stop(Seconds(total_time));

    BulkSendHelper sender2("ns3::QuicSocketFactory", sinkAddress_node5);

    sender2.SetAttribute("MaxBytes", UintegerValue(size)); // Size in bytes

    ApplicationContainer senderApps2 = sender2.Install(routers.Get(1));

    senderApps2.Start(Seconds(1.0));

    senderApps2.Stop(Seconds(total_time));

but I got this error:

$ ./ns3 run scratch/my_example.cc -- --protocol=quic
msg="Invalid value for attribute set (Protocol) on ns3::PacketSink", +0.000000000s -1 file=/mnt/sdb_disk/ns-3-dev/src/core/model/object-factory.cc, line=79
NS_FATAL, terminating
terminate called without an active exception
Command 'build/scratch/ns3-dev-my_example-default --protocol=quic' died with <Signals.SIGABRT: 6>.

[H D]

[Tommaso Pecorella]

My best guess is that you didn't install properly the quic model. Can you check if it's installed correctly by executing first the quick examples?

On Monday 29 April 2024 at 23:22:08 UTC+2 H D wrote:

[H D]

You're right, I did not compile it.

I've now downloaded the tar.gz from here - https://apps.nsnam.org/app/quic/

and I followed the instructions written there and here: https://github.com/signetlabdei/quic

Then I got this error: 

-- Skipping contrib/quic : it does not contain a CMakeLists.txt file

To solve this, I copied this file https://github.com/signetlabdei/quic/blob/master/CMakeLists.txt into the  contrib/quic/  path.

And now I'm getting the following (attached the file) compilation errors when I try to compile my program...

It seems like the command

ns-3-dev (master)$ ./ns3 configure --enable-tests --enable-examples

is executing successfully, but:

ns-3-dev (master)$ ./ns3 run scratch/my_example.cc -- --protocol=quic

is failing....

[Tommaso Pecorella]

These are typical compilation errors due to a change we made in ns-3 a while ago.

We moved away from compare-to-zero for pointers, and now you have to compare a pointer to the (more appropriate) "nullptr".

Open the sources and change the offending lines so that instead of (for example) "p != 0" it reads "p != nullptr".

A partial set of changes is here: https://github.com/signetlabdei/quic/pull/21

The changes can be accessed as a diff file using https://patch-diff.githubusercontent.com/raw/signetlabdei/quic/pull/21.diff

My suggestion is to collaborate with the model authors to fix these points, they should be relatively easy to fix.

[H D]

Ack, thank you, but I still get the following errors:

ns-3-dev (master)$ ./ns3 run scratch/my_example.cc -- --protocol=quic

Consolidate compiler generated dependencies of target libquic-obj
[  0%] Building CXX object contrib/quic/CMakeFiles/libquic-obj.dir/model/quic-congestion-ops.cc.o
[  0%] Building CXX object contrib/quic/CMakeFiles/libquic-obj.dir/model/quic-l4-protocol.cc.o
[  0%] Building CXX object contrib/quic/CMakeFiles/libquic-obj.dir/model/quic-bbr.cc.o
ns-3-dev/contrib/quic/model/quic-congestion-ops.cc: In member function ‘virtual void ns3::QuicCongestionOps::OnAckReceived(ns3::Ptr<ns3::TcpSocketState>, ns3::QuicSubheader&, std::vector<ns3::Ptr<ns3::QuicSocketTxItem> >, const ns3::RateSample*)’:
ns-3-dev/contrib/quic/model/quic-congestion-ops.cc:105:3: error: ‘NS_UNUSED’ was not declared in this scope
  105 |   NS_UNUSED (rs);
      |   ^~~~~~~~~
ns-3-dev/contrib/quic/model/quic-bbr.cc: In member function ‘virtual void ns3::QuicBbr::CongControl(ns3::Ptr<ns3::TcpSocketState>, const ns3::TcpRateOps::TcpRateConnection&, const ns3::TcpRateOps::TcpRateSample&)’:
ns-3-dev/contrib/quic/model/quic-bbr.cc:619:5:  error: ‘NS_UNUSED’ was not declared in this scope
  619 |     NS_UNUSED (rc);
      |     ^~~~~~~~~
ns-3-dev/contrib/quic/model/quic-bbr.cc: In member function ‘virtual void ns3::QuicBbr::IncreaseWindow(ns3::Ptr<ns3::TcpSocketState>,
uint32_t)’:
ns-3-dev/contrib/quic/model/quic-bbr.cc:707:3:  error: ‘NS_UNUSED’ was not declared in this scope
  707 |   NS_UNUSED (segmentsAcked);
      |   ^~~~~~~~~
gmake[3]: *** [contrib/quic/CMakeFiles/libquic-obj.dir/build.make:78: contrib/quic/CMakeFiles/libquic-obj.dir/model/quic-congestion-ops.cc.o] Error
1
gmake[3]: *** Waiting for unfinished jobs....
In file included from ns-3-dev/src/core/model/log.h:24,
                 from ns-3-dev/src/core/model/fatal-error.h:24,
                 fromns-3-dev/src/core/model/assert.h:53,
                 from ns-3-dev/build/include/ns3/assert.h:1,
                 from ns-3-dev/contrib/quic/model/quic-l4-protocol.cc:25:
ns-3-dev/contrib/quic/model/quic-l4-protocol.cc: In member function ‘virtual ns3::IpL4Protocol::RxStatus ns3::QuicL4Protocol::Receive(ns3::Ptr<ns3::Packet>, const ns3::Ipv6Header&, ns3::Ptr<ns3::Ipv6Interface>)’:
ns-3-dev/contrib/quic/model/quic-l4-protocol.cc:775:55: error: ‘const class ns3::Ipv6Header’ has no member named ‘GetSourceAddress’; did you mean ‘ns3::Ipv6Address ns3::Ipv6Header::m_sourceAddress’? (not accessible from this context)
  775 |   NS_LOG_FUNCTION (this << packet << incomingIpHeader.GetSourceAddress() <<
      |                                                                                                               ^~~~~~~~~~~~~~~~
ns-3-dev/src/core/model/log-macros-enabled.h:251:48: note: in definition of macro ‘NS_LOG_FUNCTION’
  251 |             ns3::ParameterLogger(std::clog) << parameters;                                         \
      |                                                                                 ^~~~~~~~~~
In file included from ns-3-dev/src/internet/model/ip-l4-protocol.h:27,
                 from ns-3-dev/build/include/ns3/ip-l4-protocol.h:1,
                 from ns-3-dev/contrib/quic/model/quic-l4-protocol.h:34,
                 from ns-3-dev/contrib/quic/model/quic-l4-protocol.cc:38:
ns-3-dev/src/internet/model/ipv6-header.h:303:17: note: declared private here
  303 |     Ipv6Address m_sourceAddress;
      |                                 ^~~~~~~~~~~~~~~
In file included from ns-3-dev/src/core/model/log.h:24,
                 from ns-3-dev/src/core/model/fatal-error.h:24,
                 from ns-3-dev/src/core/model/assert.h:53,
                 from ns-3-dev/build/include/ns3/assert.h:1,
                 from ns-3-dev/contrib/quic/model/quic-l4-protocol.cc:25:
ns-3-dev/contrib/quic/model/quic-l4-protocol.cc:776:37: error: ‘const class ns3::Ipv6Header’ has no member named ‘GetDestinationAddress’; did you mean ‘ns3::Ipv6Address ns3::Ipv6Header::m_destinationAddress’? (not accessible from this context)
  776 |                    incomingIpHeader.GetDestinationAddress());
      |                                                          ^~~~~~~~~~~~~~~~~~~~~
ns-3-dev/src/core/model/log-macros-enabled.h:251:48: note: in definition of macro ‘NS_LOG_FUNCTION’
  251 |             ns3::ParameterLogger(std::clog) << parameters;                                         \
      |                                                                                 ^~~~~~~~~~
In file included from ns-3-dev/src/internet/model/ip-l4-protocol.h:27,
                 from ns-3-dev/build/include/ns3/ip-l4-protocol.h:1,
                 from ns-3-dev/contrib/quic/model/quic-l4-protocol.h:34,
                 from ns-3-dev/contrib/quic/model/quic-l4-protocol.cc:38:
ns-3-dev/src/internet/model/ipv6-header.h:308:17: note: declared private here
  308 |     Ipv6Address m_destinationAddress;
      |                                 ^~~~~~~~~~~~~~~~~~~~
gmake[3]: *** [contrib/quic/CMakeFiles/libquic-obj.dir/build.make:366: contrib/quic/CMakeFiles/libquic-obj.dir/model/quic-bbr.cc.o] Error 1
gmake[3]: *** [contrib/quic/CMakeFiles/libquic-obj.dir/build.make:142: contrib/quic/CMakeFiles/libquic-obj.dir/model/quic-l4-protocol.cc.o] Error 1
gmake[2]: *** [CMakeFiles/Makefile2:4269: contrib/quic/CMakeFiles/libquic-obj.dir/all] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:17466: scratch/CMakeFiles/scratch_my_example.dir/rule] Error 2
gmake: *** [Makefile:5939: scratch_my_example] Error 2

[Tommaso Pecorella]

You're using the wrong repository....

The right one is: https://github.com/signetlabdei/quic

The one you're using is outdated.