netdev - Retransmission and packet handling in the TCP-code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <56730.129.240.228.21.1169634244.squirrel@webmail.uio.no>
Date:	Wed, 24 Jan 2007 11:24:04 +0100 (CET)
From:	kristrev@...dent.matnat.uio.no
To:	netdev@...r.kernel.org
Subject: Retransmission and packet handling in the TCP-code

Hello,

I have recently started working with the Linux-kernel TCP-code with
regards to implementing a few (hopefully good) algorithms. But I want to
make sure that I have understood everything correctly before I start
implementing, so I have a few questions.

1. Are the skb's aware of the sk_buff_head? E.g. does the prev pointer of
the last skb (the one that buff_head->next points to) in the write queue
point to buff_head or to the first skb?

2. Is the "only" thing that seperates a for instance lost packet from a
recently queued one the value of the tcp_skb_cb->sacked-variable (from the
kernels point of view)? (Except for the fact that send_head might point to
the recently queued one).

3. When a retransmission occur, are all the lost packets resent or just
n-1 of them? A couple of my friends claim that the latter is true, but I
can't find anything in the source code to support that. My theory is that
they (my friends) don't count the packet that triggers the retransmission,
even though this is also retransmitted.

4. Does the kernel bundle two and two packets (if possible) during
retransmission? The same friends that told me about the n-1-thing, also
told me that the kernel tries to bundle as many packets as possible.

But I can't find anything in the code to support this, as far as can see
it tries to bundle two packets (skb's) and sends the new packet (or this
first one, if the collapse wasnt succsessful) to tcp_transmit_skb() (and
then it is to late to bundle any more).

5. Say that you have sent three packets (called p1, p2 and p3) and p2
arrives succsessfully, but p1 doesn't and triggers a timeout. If I have
understod the code correctly, the kernel will try to collapse p1 and p3
and send the combined packet if successfully (or just p1).

If we assume that the collapse took place and that p3 got lost, how does
the reciever detect what part of the data (in the packet) belongs to p1
and p3? To me it seems that tcp_retrans_try_collapse() appends all the
data from (in this case) p3 to the data-field of p1, without e.g. marking
that the last 25 bytes belongs to p3.

Thanks in advance for any answers and have a good day :)

-Kristian

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html