LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Retransmission and packet handling in the TCP-code
@ 2007-01-24 13:33 kristrev
2007-01-24 22:34 ` David Miller
0 siblings, 1 reply; 3+ messages in thread
From: kristrev @ 2007-01-24 13:33 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Retransmission and packet handling in the TCP-code
2007-01-24 13:33 Retransmission and packet handling in the TCP-code kristrev
@ 2007-01-24 22:34 ` David Miller
2007-01-25 15:01 ` kristrev
0 siblings, 1 reply; 3+ messages in thread
From: David Miller @ 2007-01-24 22:34 UTC (permalink / raw)
To: kristrev; +Cc: linux-kernel
Can you _PLEASE_ not send this independantly to 3 different linux
mailing lists?
It WILL NOT increase the chances of someone replying to you, in fact
for the folks who are on all of those lists (like me) it will irritate
them to no end and make them NOT want to reply to your questions.
Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Retransmission and packet handling in the TCP-code
2007-01-24 22:34 ` David Miller
@ 2007-01-25 15:01 ` kristrev
0 siblings, 0 replies; 3+ messages in thread
From: kristrev @ 2007-01-25 15:01 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel
> Can you _PLEASE_ not send this independantly to 3 different linux
> mailing lists?
I am sorry, it will not happen again.
-Kristian
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-01-25 15:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-24 13:33 Retransmission and packet handling in the TCP-code kristrev
2007-01-24 22:34 ` David Miller
2007-01-25 15:01 ` kristrev
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).