| On 9/23/07, Arnaldo Carvalho de Melo [EMAIL PROTECTED] wrote:
| Trying to rebuild a proper test setup, so far using just loopback for
| simple tests I noticed this problem:
|
| Who was the last person to touch the DCCP support code in tcpdump? Care
| to take a look?
|
| - Arnaldo
Ian McDonald wrote:
| + * 16-20ms to match the typical multimedia inter-frame
interval
| + * 100ms as a reasonable compromise [default]
| + * 1000ms corresponds to the lower TCP RTO bound (RFC 2988,
2.4)
| +
|
| But Linux actually uses 250 ms
| Anyway, I'm already identifying the candidate codes to be shared
| between ccid3 and ccid4 if you didn't this yet. Another option is wait
| for gerrit suggestion on this issue and discuss more about that and
| define a strategy to avoid code repetition.
|
| See? Wait for Gerrit,
Sorry for the delay there were local bank holidays here.
| - Rewrite all the patches (from me and Tommi) and resubmit to Gerrit
| as a unique patchset, as suggested by Ian. Besides, ask Gerrit to
| overwrite the current ccid4 branch;
| - Identify and provide common code between ccid-4 and
On 9/25/07, Gerrit Renker [EMAIL PROTECTED] wrote:
Ian McDonald wrote:
| + * 16-20ms to match the typical multimedia inter-frame interval
| + * 100ms as a reasonable compromise [default]
| + * 1000ms corresponds to the lower TCP RTO bound (RFC 2988, 2.4)
| +
|
| But Linux actually
Arnaldo -
| Algorithm is fine, just use time_after when comparing jiffies based
| timestamps, here:
Many thanks for pointing this out - it was a stupid oversight. The interdiff
to the previous patch is:
* These Syncs are rate-limited as per RFC 4340, 7.5.4:
This is a resubmission for the test tree, the change to version 2 is that
ssthresh has, after cwnd, also been converted to u32; which suggested itself
since there are many operations and comparisons between these two variables.
- Patch v2
I have put the following into the repository and, since in the editor anyway,
done a
s/Copyrithg/Copyright/g
Hope that is ok.
| Signed-off-by: Leandro Sales [EMAIL PROTECTED]
|
| Please considerer pulling the following as the final patch for the [PATCH
3/4].
|
| diff -uprN
| Re-submitting my initial patchset for CCID-4, merging them against
| Tommi patcheset and providing some updates/improvements/organization.
Updated and online now at
git-pull git://eden-feed.erg.abdn.ac.uk/dccp_exp ccid4
-
To unsubscribe from this list: send the line unsubscribe dccp
Em Tue, Sep 25, 2007 at 10:58:41AM +0100, Gerrit Renker escreveu:
Arnaldo -
| Algorithm is fine, just use time_after when comparing jiffies based
| timestamps, here:
Many thanks for pointing this out - it was a stupid oversight. The interdiff
to the previous patch is:
*
| +/* rate-limit for syncs in reply to sequence-invalid packets; RFC 4340,
7.5.4 */
| +int sysctl_dccp_sync_ratelimit __read_mostly = HZ / 8;
|
| Why the extra spaces/tabs before __read_mostly?
This is for consistency with the sysctls below, the whole paragraph looks like
this:
Em Tue, Sep 25, 2007 at 01:16:53PM +0100, Gerrit Renker escreveu:
| +/* rate-limit for syncs in reply to sequence-invalid packets; RFC 4340,
7.5.4 */
| +int sysctl_dccp_sync_ratelimit __read_mostly = HZ / 8;
|
| Why the extra spaces/tabs before __read_mostly?
This is for
A small set of patches to prepare feature negotion, and one miscellaneous one.
I will start step by step, the patches will be put into the test tree after the
last batch has been set (although this time I made sure that patch sets also
compile separately).
Patch #1: Accounting, records an unused
[DCCP]: Add Support for Data 1 .. 3 fields of Reset packets
This adds fields to support the informational Data 1..3 fields of the
DCCP-Reset packets (RFC 4340, 5.6), and makes minor cosmetic changes
to documentation.
Code which fills in these fields follows in subsequent patches, it is
primarily
[DCCP]: Remove duplicate code for Reset from connected socket
In this patch, duplicated code is removed for the case when a Reset packet is
sent from a connected socket. This code duplication is between dccp_make_reset
and dccp_transmit_skb, which already contained an (up to now entirely unused)
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340,
5.6.
It is useful to have this separate, since the following Reset codes will
[DCCP]: Allow to parse options on Request Sockets
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
[DCCP]: Add (missing) option parsing to request_sock processing
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.
[DCCP]: Handle timestamps on Request/Response exchange separately
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;
*
[DCCP]: Support inserting options during the 3-way handshake
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.
Em Tue, Sep 25, 2007 at 03:23:50PM +0100, Gerrit Renker escreveu:
A small set of patches to prepare feature negotion, and one miscellaneous one.
I will start step by step, the patches will be put into the test tree after
the
last batch has been set (although this time I made sure that patch
Em Tue, Sep 25, 2007 at 03:29:52PM +0100, Gerrit Renker escreveu:
[DCCP]: Add FIXME for send_delayed_ack
This adds a FIXME to signal that the function dccp_send_delayed_ack is nowhere
used in the entire DCCP/CCID code.
Using a delayed Ack timer is suggested in 11.3 of RFC 4340, but it has
Em Tue, Sep 25, 2007 at 03:30:48PM +0100, Gerrit Renker escreveu:
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a
timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
Em Tue, Sep 25, 2007 at 03:30:51PM +0100, Gerrit Renker escreveu:
[DCCP]: Support inserting options during the 3-way handshake
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
On 9/25/07, Gerrit Renker [EMAIL PROTECTED] wrote:
This is a resubmission for the test tree, the change to version 2 is that
ssthresh has, after cwnd, also been converted to u32; which suggested itself
since there are many operations and comparisons between these two variables.
On 9/26/07, Gerrit Renker [EMAIL PROTECTED] wrote:
[DCCP]: Add FIXME for send_delayed_ack
This adds a FIXME to signal that the function dccp_send_delayed_ack is nowhere
used in the entire DCCP/CCID code.
Using a delayed Ack timer is suggested in 11.3 of RFC 4340, but it has also
rather
On 9/26/07, Gerrit Renker [EMAIL PROTECTED] wrote:
[DCCP]: Add Support for Data 1 .. 3 fields of Reset packets
This adds fields to support the informational Data 1..3 fields of the
DCCP-Reset packets (RFC 4340, 5.6), and makes minor cosmetic changes
to documentation.
Code which fills in
On 9/26/07, Gerrit Renker [EMAIL PROTECTED] wrote:
[DCCP]: Remove duplicate code for Reset from connected socket
In this patch, duplicated code is removed for the case when a Reset packet is
sent from a connected socket. This code duplication is between dccp_make_reset
and dccp_transmit_skb,
On 9/26/07, Gerrit Renker [EMAIL PROTECTED] wrote:
[DCCP]: Factor out common code for generating Resets
This factors code common to dccp_v{4,6}_ctl_send_reset into a separate
function,
and adds support for filling in the Data 1 ... Data 3 fields from RFC 4340,
5.6.
It is useful to have
On 9/26/07, Gerrit Renker [EMAIL PROTECTED] wrote:
[DCCP]: Allow to parse options on Request Sockets
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).
On 9/26/07, Gerrit Renker [EMAIL PROTECTED] wrote:
[DCCP]: Add (missing) option parsing to request_sock processing
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
On 9/26/07, Gerrit Renker [EMAIL PROTECTED] wrote:
[DCCP]: Support inserting options during the 3-way handshake
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
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Sat, 22 Sep 2007 18:09:17 -0300
This patch reduces the number of timestamps taken in the receive path
for each packet.
The ccid3_hc_tx_update_x() routine is called in
* the receive path for each CCID3-controlled packet
* for the
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Sat, 22 Sep 2007 18:09:37 -0300
This provides a timesource, conveniently used for DCCP timestamps, which
returns the elapsed time in 10s of microseconds since initialisation.
This makes for a wrap-around time of about 11.9 hours, which
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Sat, 22 Sep 2007 18:10:08 -0300
This patch is in part required by the next patch; it
* replaces 6 instances of `DCCP_SKB_CB(skb)-dccpd_seq' with `seqno';
* replaces 7 instances of `DCCP_SKB_CB(skb)-dccpd_ack_seq' with `ackno';
*
From: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
Date: Sat, 22 Sep 2007 18:10:33 -0300
The parameter `seq' of dccp_send_sync() is in fact an acknowledgement number
and not a sequence number - thus renamed by this patch into `ackno'.
Secondly, a `critical' warning is added when a Sync/SyncAck
36 matches
Mail list logo
