LEFT | RIGHT |
(no file at all) | |
1 <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> | 1 <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> |
2 <html> | 2 <html> |
3 <head> | 3 <head> |
4 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> | 4 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
5 <title>ns-3 Change Log</title> | 5 <title>ns-3 Change Log</title> |
6 </head> | 6 </head> |
7 <body> | 7 <body> |
8 | 8 |
9 <h1> | 9 <h1> |
10 ns-3: API and model change history</h1> | 10 ns-3: API and model change history</h1> |
(...skipping 57 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
68 user priority is set to the three most significant bits of the DS field | 68 user priority is set to the three most significant bits of the DS field |
69 (TOS field in case of IPv4 and Traffic Class field in case of IPv6). The | 69 (TOS field in case of IPv4 and Traffic Class field in case of IPv6). The |
70 packet priority carried by the SocketPriorityTag is set to the user priority
. | 70 packet priority carried by the SocketPriorityTag is set to the user priority
. |
71 </li> | 71 </li> |
72 <li>The <b>PfifoFastQueueDisc</b> classifies packets into bands based on their p
riority. | 72 <li>The <b>PfifoFastQueueDisc</b> classifies packets into bands based on their p
riority. |
73 See the pfifo_fast queue disc section of the Traffic Control Layer model | 73 See the pfifo_fast queue disc section of the Traffic Control Layer model |
74 for more information. | 74 for more information. |
75 </li> | 75 </li> |
76 <li> A new class <b>SpectrumWifiPhy</b> has been introduced that makes use of th
e Spectrum module. Its functionality and API is currently very similar to that
of the YansWifiPhy, especially because it reuses the same InterferenceHelper and
ErrorModel classes (for this release). Some example programs in the 'examples/
wireless/' directory, such as 'wifi-spectrum-per-example.cc', illustrate how the
SpectrumWifiPhy class can be substituted for the default YansWifiPhy PHY model. | 76 <li> A new class <b>SpectrumWifiPhy</b> has been introduced that makes use of th
e Spectrum module. Its functionality and API is currently very similar to that
of the YansWifiPhy, especially because it reuses the same InterferenceHelper and
ErrorModel classes (for this release). Some example programs in the 'examples/
wireless/' directory, such as 'wifi-spectrum-per-example.cc', illustrate how the
SpectrumWifiPhy class can be substituted for the default YansWifiPhy PHY model. |
77 </li> | 77 </li> |
| 78 <li> We have added support for generating traces for the |
| 79 <a href="https://wilseypa.github.io/desMetrics/>DES Metrics</a> project. |
| 80 These can be enabled by adding <tt>--enable-des-metrics</tt> at configuration; |
| 81 you must also use <tt>CommandLine</tt> in your script. See the API docs |
| 82 for class <tt>DesMetrics</tt> for more details. |
78 </ul> | 83 </ul> |
79 <h2>Changes to existing API:</h2> | 84 <h2>Changes to existing API:</h2> |
80 <ul> | 85 <ul> |
81 <li>SocketAddressTag was a long-standing API glitch. It was used to replicate· | 86 <li>SocketAddressTag was a long-standing API glitch. It was used to replicate· |
82 the RecvFrom effect (i.e., to know the source address of packet) without· | 87 the RecvFrom effect (i.e., to know the source address of packet) without· |
83 calling RecvFrom. | 88 calling RecvFrom. |
84 This option is more harmful than useful, because in case of tunnels the· | 89 This option is more harmful than useful, because in case of tunnels the· |
85 new tag needs to replace the old one. Moreover, there is no real need· | 90 new tag needs to replace the old one. Moreover, there is no real need· |
86 to create a new API when there is a perfectly working one (i.e., RecvFrom). | 91 to create a new API when there is a perfectly working one (i.e., RecvFrom). |
87 As a consequence, SocketAddressTag has been completely removed from ns-3. | 92 As a consequence, SocketAddressTag has been completely removed from ns-3. |
(...skipping 66 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
154 <ul> | 159 <ul> |
155 <li> RED and CoDel are no longer specializations of the Queue classe, but
are now specializations of the new QueueDisc class. This means that RED and CoDe
l can now be installed in the context of the new Traffic Control layer instead o
f as queues in (some) NetDevices. The reason for such a change is to make the ns
-3 stack much more similar to that of real operating systems (Linux has been tak
en as a reference). Queuing disciplines such as RED and CoDel can now be tested
with all the NetDevices, including WifiNetDevices. </li> | 160 <li> RED and CoDel are no longer specializations of the Queue classe, but
are now specializations of the new QueueDisc class. This means that RED and CoDe
l can now be installed in the context of the new Traffic Control layer instead o
f as queues in (some) NetDevices. The reason for such a change is to make the ns
-3 stack much more similar to that of real operating systems (Linux has been tak
en as a reference). Queuing disciplines such as RED and CoDel can now be tested
with all the NetDevices, including WifiNetDevices. </li> |
156 <li> NetDevices still use queues to buffer packets. The only subclass of Q
ueue currently available for this purpose is DropTailQueue. If one wants to appr
oximate the old behavior, one needs to set the DropTailQueue MaxPackets attribut
e to very low values, e.g., 1.</li> | 161 <li> NetDevices still use queues to buffer packets. The only subclass of Q
ueue currently available for this purpose is DropTailQueue. If one wants to appr
oximate the old behavior, one needs to set the DropTailQueue MaxPackets attribut
e to very low values, e.g., 1.</li> |
157 <li> The Traffic Control layer features a mechanism by which packets dropp
ed by the NetDevice are requeued in the queue disc (more precisely: if NetDevice
::Send returns false, the packet is requeued), so that they are retransmitted la
ter. This means that the MAC drop traces may include packets that have not been
actually lost, because they have been dropped by the device, requeued by the tra
ffic control layer and successfully retransmitted. To get the correct number of
packets that have been actually lost, one has to subtract the number of packets
requeued from the number of packets dropped as reported by the MAC drop trace. <
/li> | 162 <li> The Traffic Control layer features a mechanism by which packets dropp
ed by the NetDevice are requeued in the queue disc (more precisely: if NetDevice
::Send returns false, the packet is requeued), so that they are retransmitted la
ter. This means that the MAC drop traces may include packets that have not been
actually lost, because they have been dropped by the device, requeued by the tra
ffic control layer and successfully retransmitted. To get the correct number of
packets that have been actually lost, one has to subtract the number of packets
requeued from the number of packets dropped as reported by the MAC drop trace. <
/li> |
158 </ul> | 163 </ul> |
159 </li> | 164 </li> |
160 </ul> | 165 </ul> |
161 <h2>Changes to build system:</h2> | 166 <h2>Changes to build system:</h2> |
162 <ul> | 167 <ul> |
163 <li> Waf was upgraded to 1.8.19</li> | 168 <li> Waf was upgraded to 1.8.19</li> |
164 <li> A new waf build option, --check-profile, was added to allow users to chec
k the currently active build profile. It is discussed in bug 2202 in the tracke
r.</li> | 169 <li> A new waf build option, <tt>--check-profile</tt>, was added to allow user
s to check the currently active build profile. It is discussed in bug 2202 in t
he tracker.</li> |
165 </ul> | 170 </ul> |
166 <h2>Changed behavior:</h2> | 171 <h2>Changed behavior:</h2> |
167 This section is for behavioral changes to the models that were not due to a bug
fix. | 172 This section is for behavioral changes to the models that were not due to a bug
fix. |
168 <ul> | 173 <ul> |
169 <li>TCP behavioral changes: | 174 <li>TCP behavioral changes: |
170 <ul> | 175 <ul> |
171 <li>TCP closes connection after a number of failed segment retries, | 176 <li>TCP closes connection after a number of failed segment retries, |
172 rather than trying indefinitely. The maximum number of retries, for both
SYN | 177 rather than trying indefinitely. The maximum number of retries, for both
SYN |
173 attempts and data attempts, is controlled by attributes.</li> | 178 attempts and data attempts, is controlled by attributes.</li> |
174 <li>Congestion algorithms not compliant with Fast Retransmit | 179 <li>Congestion algorithms not compliant with Fast Retransmit |
(...skipping 2523 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
2698 interval from hello interval. This is an important bug fix as | 2703 interval from hello interval. This is an important bug fix as |
2699 hold time == refresh time was never intentional, as it leads to | 2704 hold time == refresh time was never intentional, as it leads to |
2700 instability in neighbor detection. | 2705 instability in neighbor detection. |
2701 </ul> | 2706 </ul> |
2702 </li> | 2707 </li> |
2703 | 2708 |
2704 </ul> | 2709 </ul> |
2705 | 2710 |
2706 </body> | 2711 </body> |
2707 </html> | 2712 </html> |
LEFT | RIGHT |