User avatar None

String updated in the repository
Brakmo, L. S., O'Malley, S. W., and Peterson, L. L., `TCP Vegas: new techniques for congestion detection and avoidance <http://doi.acm.org/10.1145/190314.190317>`_. In Proceedings of the Conference on Communications Architectures, Protocols and Applications (London, United Kingdom, August 31 - September 02, 1994). SIGCOMM '94. ACM, New York, NY, 24-35.
Brakmo, L. S., O'Malley, S. W., and Peterson, L. L., `TCP Vegas: new techniques for congestion detection and avoidance <http://doi.acm.org/10.1145/190314.190317>`_. In Proceedings of the Conference on Communications Architectures, Protocols and Applications (London, United Kingdom, August 31 - September 02, 1994). SIGCOMM '94. ACM, New York, NY, 24-35.
4 years ago
User avatar None

String updated in the repository
Bhatia, M., Manral, V., Ohara, Y., `IS-IS and OSPF Difference Discussions <http://tools.ietf.org/html/draft-bhatia-manral-diff-isis-ospf-01>`_, work in progress, Internet draft, Jan. 2006
Bhatia, M., Manral, V., Ohara, Y., `IS-IS and OSPF Difference Discussions <http://tools.ietf.org/html/draft-bhatia-manral-diff-isis-ospf-01>`_, work in progress, Internet draft, Jan. 2006
4 years ago
User avatar None

String updated in the repository
Biondi, P. and A. Ebalard, `IPv6 Routing Header Security <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>`_, CanSecWest Security Conference 2007, April 2007.
Biondi, P. and A. Ebalard, `IPv6 Routing Header Security <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>`_, CanSecWest Security Conference 2007, April 2007.
4 years ago
User avatar None

String updated in the repository
Berners-Lee, T., `Information Management: A Proposal <http://www.w3.org/History/1989/proposal.html>`_, March 1989
Berners-Lee, T., `Information Management: A Proposal <http://www.w3.org/History/1989/proposal.html>`_, March 1989
4 years ago
User avatar None

String updated in the repository
Arlitt, M. and Williamson, C. 2005. `An analysis of TCP reset behaviour on the internet <http://doi.acm.org/10.1145/1052812.1052823>`_. SIGCOMM Computer Communication Review 35, 1 (Jan. 2005), 37-44.
Arlitt, M. and Williamson, C. 2005. `An analysis of TCP reset behaviour on the internet <http://doi.acm.org/10.1145/1052812.1052823>`_. SIGCOMM Computer Communication Review 35, 1 (Jan. 2005), 37-44.
4 years ago
User avatar None

String updated in the repository
Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J. and Jahanian, F., `Internet inter-domain traffic <http://doi.acm.org/10.1145/1851182.1851194>`_. In Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM (SIGCOMM '10). ACM, New York, NY, USA, 75-86.
Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J. and Jahanian, F., `Internet inter-domain traffic <http://doi.acm.org/10.1145/1851182.1851194>`_. In Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM (SIGCOMM '10). ACM, New York, NY, USA, 75-86.
4 years ago
User avatar None

String updated in the repository
Anderson, B. and McGrew, D., 2019, October. `TLS Beyond the Browser: Combining End Host and Network Data to Understand Application Behavior <https://doi.org/10.1145/3355369.3355601>`_. In Proceedings of the Internet Measurement Conference (pp. 379-392). ACM.
Anderson, B. and McGrew, D., 2019, October. `TLS Beyond the Browser: Combining End Host and Network Data to Understand Application Behavior <https://doi.org/10.1145/3355369.3355601>`_. In Proceedings of the Internet Measurement Conference (pp. 379-392). ACM.
4 years ago
User avatar None

String updated in the repository
Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F., Friedman, T., Latapy, M., Magnien, C., Teixeira, R., `Avoiding traceroute anomalies with Paris traceroute <https://dx.doi.org/10.1145/1177080.1177100>`_, Internet Measurement Conference, October 2006, See also http://www.paris-traceroute.net/
Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F., Friedman, T., Latapy, M., Magnien, C., Teixeira, R., `Avoiding traceroute anomalies with Paris traceroute <https://dx.doi.org/10.1145/1177080.1177100>`_, Internet Measurement Conference, October 2006, See also http://www.paris-traceroute.net/
4 years ago
User avatar None

String updated in the repository
IEEE, Std 802-2001 : IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, Available from http://standards.ieee.org/getieee802/download/802-2001.pdf
IEEE, Std 802-2001 : IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, Available from http://standards.ieee.org/getieee802/download/802-2001.pdf
4 years ago
User avatar None

String updated in the repository
IEEE 802.2-1998 (ISO/IEC 8802-2:1998), IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements--Part 2: Logical Link Control. Available from http://standards.ieee.org/getieee802/802.2.html
IEEE 802.2-1998 (ISO/IEC 8802-2:1998), IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements--Part 2: Logical Link Control. Available from http://standards.ieee.org/getieee802/802.2.html
4 years ago
User avatar None

String updated in the repository
LAN/MAN Standards Committee of the IEEE Computer Society, `IEEE Standard for Local and metropolitan area networks— Virtual Bridged Local Area Networks <http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf>`_, 2005,
LAN/MAN Standards Committee of the IEEE Computer Society, `IEEE Standard for Local and metropolitan area networks— Virtual Bridged Local Area Networks <http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf>`_, 2005,
4 years ago
User avatar None

String updated in the repository
LAN/MAN Standards Committee of the IEEE Computer Society, `IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges <http://standards.ieee.org/getieee802/download/802.1D-2004.pdf>`_ , IEEE Std 802.1DTM-2004, 2004,
LAN/MAN Standards Committee of the IEEE Computer Society, `IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Bridges <http://standards.ieee.org/getieee802/download/802.1D-2004.pdf>`_ , IEEE Std 802.1DTM-2004, 2004,
4 years ago
User avatar None

Resource updated
File “locale/pot/protocols/transport.pot” was added. 4 years ago
User avatar None

Resource updated
File “locale/pot/protocols/transport-service.pot” was added. 4 years ago
User avatar None

Resource updated
File “locale/pot/protocols/tls.pot” was added. 4 years ago
User avatar None

Resource updated
File “locale/pot/protocols/tcp.pot” was added. 4 years ago
User avatar None

String updated in the repository
The :math:`2*MSL` seconds delay in the `TIME\_WAIT` state is an important operational problem on servers having thousands of simultaneously opened TCP connections [FTY99]_. Consider for example a busy web server that processes 10.000 TCP connections every second. If each of these connections remains in the `TIME\_WAIT` state for 4 minutes, this implies that the server would have to maintain more than 2 million TCBs at any time. For this reason, some TCP implementations prefer to perform an abrupt connection release by sending a `RST` segment to close the connection [AW05]_ and immediately discard the corresponding :term:`TCB`. However, if the `RST` segment is lost, the remote host continues to maintain a :term:`TCB` for a connection that no longer exists. This optimization reduces the number of TCBs maintained by the host sending the `RST` segment but at the potential cost of increased processing on the remote host when the `RST` segment is lost.
The :math:`2*MSL` seconds delay in the `TIME\_WAIT` state is an important operational problem on servers having thousands of simultaneously opened TCP connections [FTY99]_. Consider for example a busy web server that processes 10.000 TCP connections every second. If each of these connections remains in the `TIME\_WAIT` state for 4 minutes, this implies that the server would have to maintain more than 2 million TCBs at any time. For this reason, some TCP implementations prefer to perform an abrupt connection release by sending a `RST` segment to close the connection [AW05]_ and immediately discard the corresponding :term:`TCB`. However, if the `RST` segment is lost, the remote host continues to maintain a :term:`TCB` for a connection that no longer exists. This optimization reduces the number of TCBs maintained by the host sending the `RST` segment but at the potential cost of increased processing on the remote host when the `RST` segment is lost.
4 years ago
User avatar None

String updated in the repository
The second path is when the host has transmitted all data. Assume that the last transmitted sequence number is `z`. Then, the host sends a `FIN` segment with sequence number :math:`(z+1) \pmod{2^{32}}` and enters the `FIN_WAIT1` state. In this state, it can retransmit unacknowledged segments but cannot send new data segments. It waits for an acknowledgment of its `FIN` segment (i.e. sequence number :math:`(z+1) \pmod{2^{32}}`), but may receive a `FIN` segment sent by the remote host. In the first case, the TCP connection enters the `FIN\_WAIT2` state. In this state, new data segments from the remote host are still accepted until the reception of the `FIN` segment. The acknowledgment for this `FIN` segment is sent once all data received before the `FIN` segment have been delivered to the user and the connection enters the `TIME\_WAIT` state. In the second case, a `FIN` segment is received and the connection enters the `Closing` state once all data received from the remote host have been delivered to the user. In this state, no new data segments can be sent and the host waits for an acknowledgment of its `FIN` segment before entering the `TIME\_WAIT` state.
The second path is when the host has transmitted all data. Assume that the last transmitted sequence number is `z`. Then, the host sends a `FIN` segment with sequence number :math:`(z+1) \pmod{2^{32}}` and enters the `FIN_WAIT1` state. In this state, it can retransmit unacknowledged segments but cannot send new data segments. It waits for an acknowledgment of its `FIN` segment (i.e. sequence number :math:`(z+1) \pmod{2^{32}}`), but may receive a `FIN` segment sent by the remote host. In the first case, the TCP connection enters the `FIN\_WAIT2` state. In this state, new data segments from the remote host are still accepted until the reception of the `FIN` segment. The acknowledgment for this `FIN` segment is sent once all data received before the `FIN` segment have been delivered to the user and the connection enters the `TIME\_WAIT` state. In the second case, a `FIN` segment is received and the connection enters the `Closing` state once all data received from the remote host have been delivered to the user. In this state, no new data segments can be sent and the host waits for an acknowledgment of its `FIN` segment before entering the `TIME\_WAIT` state.
4 years ago
User avatar None

Resource updated
File “locale/pot/protocols/ssh.pot” was added. 4 years ago
User avatar None

Resource updated
File “locale/pot/protocols/rpc.pot” was added. 4 years ago

Search