<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="FeedCreator 1.8" -->
<?xml-stylesheet href="https://wiki.nplab.de/lib/exe/css.php?s=feed" type="text/css"?>
<rdf:RDF
    xmlns="http://purl.org/rss/1.0/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel rdf:about="https://wiki.nplab.de/feed.php">
        <title>NPLab - public</title>
        <description></description>
        <link>https://wiki.nplab.de/</link>
        <image rdf:resource="https://wiki.nplab.de/lib/exe/fetch.php?media=wiki:dokuwiki.svg" />
       <dc:date>2026-04-30T14:54:24+00:00</dc:date>
        <items>
            <rdf:Seq>
                <rdf:li rdf:resource="https://wiki.nplab.de/doku.php?id=public:congestion_avoidance_on_a_lossy_link&amp;rev=1626102926&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.nplab.de/doku.php?id=public:impressum&amp;rev=1713878187&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.nplab.de/doku.php?id=public:omnet_inet_packetdrill&amp;rev=1626103040&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.nplab.de/doku.php?id=public:sendqueuelimit&amp;rev=1626103132&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.nplab.de/doku.php?id=public:send_acknowledgment&amp;rev=1626103077&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.nplab.de/doku.php?id=public:sizing_router_buffer&amp;rev=1626101266&amp;do=diff"/>
                <rdf:li rdf:resource="https://wiki.nplab.de/doku.php?id=public:start&amp;rev=1626101560&amp;do=diff"/>
            </rdf:Seq>
        </items>
    </channel>
    <image rdf:about="https://wiki.nplab.de/lib/exe/fetch.php?media=wiki:dokuwiki.svg">
        <title>NPLab</title>
        <link>https://wiki.nplab.de/</link>
        <url>https://wiki.nplab.de/lib/exe/fetch.php?media=wiki:dokuwiki.svg</url>
    </image>
    <item rdf:about="https://wiki.nplab.de/doku.php?id=public:congestion_avoidance_on_a_lossy_link&amp;rev=1626102926&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2021-07-12T15:15:26+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>congestion_avoidance_on_a_lossy_link</title>
        <link>https://wiki.nplab.de/doku.php?id=public:congestion_avoidance_on_a_lossy_link&amp;rev=1626102926&amp;do=diff</link>
        <description>Congestion Avoidance on a lossy link

Mathis et. al. gave us in its paper The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm a simple formula for throughput for specific scenario.
The scenario is a single TCP sender sends full sized segments to a TCP receiver over a link with high bandwidth, a constant delay, and a fixed packet loss rate.
The condition for the formula is that the bandwidth is high enough, such that the fixed packet loss limits the throughput.</description>
    </item>
    <item rdf:about="https://wiki.nplab.de/doku.php?id=public:impressum&amp;rev=1713878187&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2024-04-23T13:16:27+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>impressum</title>
        <link>https://wiki.nplab.de/doku.php?id=public:impressum&amp;rev=1713878187&amp;do=diff</link>
        <description>Impressum

Angaben gemäß § 5 TMG

FH Münster University of Applied Sciences

vertreten durch den Präsidenten

Hüfferstraße 27, 48149 Münster

Umsatzsteuer-ID-Nummer: DE 154136385

Aufsichtsbehörde

Ministerium für Kultur und Wissenschaft des Landes Nordrhein-Westfalen</description>
    </item>
    <item rdf:about="https://wiki.nplab.de/doku.php?id=public:omnet_inet_packetdrill&amp;rev=1626103040&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2021-07-12T15:17:20+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>omnet_inet_packetdrill</title>
        <link>https://wiki.nplab.de/doku.php?id=public:omnet_inet_packetdrill&amp;rev=1626103040&amp;do=diff</link>
        <description>OMNeT++/INET Packetdrill

Packetdrill in INET consists of

	*  Node (src/inet/node/packetdrill/PacketDrillQuicHost.ned)
	*  Tests (tests/packetdrill)
	*  Application (src/inet/applications/packetdrill)

With a Packetdrill test script, it is possible to check the content and the time of packets a host sends.   The expected behavior is described in the script (in a line with</description>
    </item>
    <item rdf:about="https://wiki.nplab.de/doku.php?id=public:sendqueuelimit&amp;rev=1626103132&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2021-07-12T15:18:52+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>sendqueuelimit</title>
        <link>https://wiki.nplab.de/doku.php?id=public:sendqueuelimit&amp;rev=1626103132&amp;do=diff</link>
        <description>sendQueueLimit

QUIC uses the parameter sendQueueLimit to limit the size of total data in the send queues of the streams. The send queue includes unsent data, sent but unacked data, and lost data. When we reach this limit, we notify the application that we are not able to accept any more data. If this happens, we wait until the size of total data in the send queues is down to (sendQueueLimit * sendQueueLowWaterRatio), before we notify the application that we are able to accept data again.</description>
    </item>
    <item rdf:about="https://wiki.nplab.de/doku.php?id=public:send_acknowledgment&amp;rev=1626103077&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2021-07-12T15:17:57+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>send_acknowledgment</title>
        <link>https://wiki.nplab.de/doku.php?id=public:send_acknowledgment&amp;rev=1626103077&amp;do=diff</link>
        <description>When to send an acknowledgment?

From quic-transport-24 draft, section 13.2.

	&quot;   Endpoints acknowledge all packets they receive and process.  However,
   only ack-eliciting packets cause an ACK frame to be sent within the
   maximum ack delay.  Packets that are not ack-eliciting are only</description>
    </item>
    <item rdf:about="https://wiki.nplab.de/doku.php?id=public:sizing_router_buffer&amp;rev=1626101266&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2021-07-12T14:47:46+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>sizing_router_buffer</title>
        <link>https://wiki.nplab.de/doku.php?id=public:sizing_router_buffer&amp;rev=1626101266&amp;do=diff</link>
        <description>Sizing Router Buffer

For a single long lived QUIC connection over a bottleneck link, what is the best buffer size for the router before the bottleneck link. A buffer that is too big adds queuing delay. A buffer that is too small has a negative effect on the throughput.</description>
    </item>
    <item rdf:about="https://wiki.nplab.de/doku.php?id=public:start&amp;rev=1626101560&amp;do=diff">
        <dc:format>text/html</dc:format>
        <dc:date>2021-07-12T14:52:40+00:00</dc:date>
        <dc:creator>Anonymous (anonymous@undisclosed.example.com)</dc:creator>
        <title>start</title>
        <link>https://wiki.nplab.de/doku.php?id=public:start&amp;rev=1626101560&amp;do=diff</link>
        <description>Public Documents

QUIC Simulation

	*  Congestion Avoidance on a lossy link
	*  OMNeT INET Packetdrill
	*  Send Acknowledgment
	*  sendQueueLimit
	*  Sizing Router Buffer</description>
    </item>
</rdf:RDF>
