LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: kristrev@student.matnat.uio.no
To: linux-kernel@vger.kernel.org
Subject: Retransmission and packet handling in the TCP-code
Date: Wed, 24 Jan 2007 14:33:35 +0100 (CET)	[thread overview]
Message-ID: <60609.129.240.228.21.1169645615.squirrel@webmail.uio.no> (raw)
In-Reply-To: 

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





             reply	other threads:[~2007-01-24 13:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24 13:33 kristrev [this message]
2007-01-24 22:34 ` David Miller
2007-01-25 15:01   ` kristrev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=60609.129.240.228.21.1169645615.squirrel@webmail.uio.no \
    --to=kristrev@student.matnat.uio.no \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: Retransmission and packet handling in the TCP-code' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).