Burak
I have tried to replay your results but can not find anything wrong with the
current test kernel.
Please have a look at the results below, I repeated the same experiment on two
different testbeds.
Incidentally, these results agree with the values you observed for TCP Reno. It
seems that
Gerrit,
I am cloning your tree with the following command:
git-clone git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp
But I did not check out the DCCP sub-branch, by:
git-checkout --track -b dccp origin/dccp
However, as I type this command above, git complains saying:
git
| git-clone git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp
|
|
| But I did not check out the DCCP sub-branch, by:
|
| git-checkout --track -b dccp origin/dccp
|
|
| However, as I type this command above, git complains saying:
|
| git checkout: branch dccp already exists
|
|
|
I've been working on making DCCP Ack Vectors more robust, dealing more
gracefully
with buffer overflow, and fixing two cases which will lead to corrupted buffer
state.
The encountered problems and implementation strategy are documented on
From: Gerrit Renker [EMAIL PROTECTED]
This replaces 4 individual assignments for `len' with a single
one, placed where the control flow of those 4 leads to.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL PROTECTED]
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL
From: Gerrit Renker [EMAIL PROTECTED]
When performing active close, RFC 4340, 8.3. requires to retransmit the
Close/CloseReq with a backoff-retransmit timer starting at intially 2 RTTs.
This patch shifts the existing code for active-close retransmit timer
into output.c, so that the retransmit
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.25
Best Regards,
- Arnaldo
Documentation/networking/dccp.txt |6 +
include/linux/dccp.h | 24 ++-
net/dccp/dccp.h | 10 ++-
net/dccp/feat.c
From: Gerrit Renker [EMAIL PROTECTED]
The option parsing code currently only parses on full sk's. This causes a
problem for
options sent during the initial handshake (in particular timestamps and
feature-negotiation
options). Therefore, this patch extends the option parsing code with an
From: Gerrit Renker [EMAIL PROTECTED]
This provides a separate routine to insert options during the initial handshake.
The main purpose is to conduct feature negotiation, for the moment the only user
is the timestamp echo needed for the (CCID3) handshake RTT sample.
Padding of options has been
From: Gerrit Renker [EMAIL PROTECTED]
This adds option-parsing code to processing of Acks in the listening state
on request_socks on the server, serving two purposes
(i) resolves a FIXME (removed);
(ii) paves the way for feature-negotiation during connection-setup.
There is an intended
From: Gerrit Renker [EMAIL PROTECTED]
This implements [RFC 4340, p. 32]: any feature negotiation options received
on DCCP-Data packets MUST be ignored.
Also added a FIXME for further processing, since the code currently (wrongly)
classifies empty Confirm options as invalid - this needs to be
From: Gerrit Renker [EMAIL PROTECTED]
This patch performs two changes:
1) Close the write-end in addition to the read-end when a fin-like segment
(Close or CloseReq) is received by DCCP. This accounts for the fact that DCCP,
in contrast to TCP, does not have a half-close. RFC 4340 says in
From: Gerrit Renker [EMAIL PROTECTED]
This removes another Fixme, using the TCP maximum RTO rather than the value
specified by the DCCP specification. Across the sections in RFC 4340, 64
seconds is consistently suggested as maximum RTO backoff value; and this is
the value which is now used.
I
From: Gerrit Renker [EMAIL PROTECTED]
This adds a socket option and signalling support for the case where the server
holds timewait state on closing the connection, as described in RFC 4340, 8.3.
Since holding timewait state at the server is the non-usual case, it is enabled
via a socket option.
From: Gerrit Renker [EMAIL PROTECTED]
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo)
on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 13:05:53 -0200
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.25
Looks good, pulled and pushed back out to net-2.6.25
Thanks!
-
To unsubscribe from this list: send the line
From: Gerrit Renker [EMAIL PROTECTED]
This adds documentation for the ccid_operations structure.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Signed-off-by: Ian McDonald [EMAIL PROTECTED]
Signed-off-by: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
net/dccp/ccid.h | 35
From: Gerrit Renker [EMAIL PROTECTED]
The patch makes the registration messages of CCID 2/3 a bit more
informative: instead of repeating the CCID number as currently done,
CCID: Registered CCID 2 (ccid2) or
CCID: Registered CCID 3 (ccid3),
the descriptive names of the CCID's
From: Gerrit Renker [EMAIL PROTECTED]
This introduces a CCMPS field for setting a CCID-specific upper bound on the
application payload
size, as is defined in RFC 4340, section 14.
Only the TX CCID is considered in setting this limit, since the RX CCID
generates comparatively
small (DCCP-Ack)
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.25
Best Regards,
- Arnaldo
net/dccp/ccid.c|8
net/dccp/ccid.h| 37 ++---
net/dccp/ccids/ccid2.c |2 +-
20 matches
Mail list logo
