Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(1078)

Delta Between Two Patch Sets: CHANGES.html

Issue 301230043: Support DES Metrics traces (Closed)
Left Patch Set: Add CommandLine to all examples Created 7 years, 8 months ago
Right Patch Set: Unified patch 2 and 3, to see des-metrics in its entirety. Created 7 years, 7 months ago
Left:
Right:
Use n/p to move between diff chunks; N/P to move between comments. Please Sign in to add in-line comments.
Jump to:
Right: Side by side diff | Download
« no previous file with change/comment | « .hgignore ('k') | RELEASE_NOTES » ('j') | no next file with change/comment »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
LEFTRIGHT
(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
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
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
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>
LEFTRIGHT

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b