Why the stream stop when i try quic-tester-stream.cc
liuyi12138 opened this issue · 11 comments
As i said, when i try to use quic-tester-stream.cc,it stop at 0.016s, and show MAX_DATA
i don't known how to sovle it
the trace:
- 0.0161728 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 4 protocol 17 offset (bytes) 0 flags [none] length: 51 10.1.1.1 > 10.1.1.2) ns3::UdpHeader (length: 31 49153 > 9) ns3::QuicHeader (|0|1|0|1|0|1 Octet|
|ConnectionID 16215117342755731456|
|PacketNumber 5|
) ns3::QuicSubHeader (|MAX_DATA|
|Maximum Data 262144|
) ns3::QuicSubHeader (|ACK|
|Largest Acknowledged 4|
|Ack Delay 292|
|Ack Block Count 1|
|First Ack Block 4|
|Gap 2|
|Additional Ack Block 1|
As i said, when i try to use quic-tester-stream.cc,it stop at 0.016s, and show MAX_DATA
i don't known how to sovle it
the trace:
- 0.0161728 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue ns3::PppHeader (Point-to-Point Protocol: IP (0x0021)) ns3::Ipv4Header (tos 0x0 DSCP Default ECN Not-ECT ttl 64 id 4 protocol 17 offset (bytes) 0 flags [none] length: 51 10.1.1.1 > 10.1.1.2) ns3::UdpHeader (length: 31 49153 > 9) ns3::QuicHeader (|0|1|0|1|0|1 Octet|
|ConnectionID 16215117342755731456|
|PacketNumber 5|
) ns3::QuicSubHeader (|MAX_DATA|
|Maximum Data 262144|
) ns3::QuicSubHeader (|ACK|
|Largest Acknowledged 4|
|Ack Delay 292|
|Ack Block Count 1|
|First Ack Block 4|
|Gap 2|
|Additional Ack Block 1|
Hi,
are you using the unmodified example with the latest version of the code?
no, i change the "Interval" to be larger,and it happened.
then i changed it back, and it works good,
I guess you didn't track ack in this project, which led to the situation i found.
Hi, to which interval are you referring to - and which value did you select?
dlClient.SetAttribute ("Interval", TimeValue (MicroSeconds(1000)));
I choose the Interval time as 1s
Hi, the simulation works fine on my machine with 1s as interval. Are you using the latest version of the code?
Hi, if you send only one packet per second your throughput will be low. At the beginning you may have some overhead due to control packets..
but why it send the MAX_DATA packets? Shouldn't it stop contracting
Solved in the new pull request, MAX_DATA packets are sent more rarely