2005-09-18 15:17:51 +08:00
|
|
|
/*
|
|
|
|
* net/dccp/ackvec.c
|
|
|
|
*
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
* An implementation of Ack Vectors for the DCCP protocol
|
|
|
|
* Copyright (c) 2007 University of Aberdeen, Scotland, UK
|
2005-09-18 15:17:51 +08:00
|
|
|
* Copyright (c) 2005 Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License as published by the
|
|
|
|
* Free Software Foundation; version 2 of the License;
|
|
|
|
*/
|
|
|
|
#include "dccp.h"
|
2006-03-21 09:16:17 +08:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/slab.h>
|
2005-09-18 15:17:51 +08:00
|
|
|
|
2006-12-07 12:33:20 +08:00
|
|
|
static struct kmem_cache *dccp_ackvec_slab;
|
|
|
|
static struct kmem_cache *dccp_ackvec_record_slab;
|
2006-03-21 09:19:55 +08:00
|
|
|
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
struct dccp_ackvec *dccp_ackvec_alloc(const gfp_t priority)
|
2006-03-21 09:19:55 +08:00
|
|
|
{
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
struct dccp_ackvec *av = kmem_cache_zalloc(dccp_ackvec_slab, priority);
|
|
|
|
|
|
|
|
if (av != NULL) {
|
dccp ccid-2: Implementation of circular Ack Vector buffer with overflow handling
This completes the implementation of a circular buffer for Ack Vectors, by
extending the current (linear array-based) implementation. The changes are:
(a) An `overflow' flag to deal with the case of overflow. As before, dynamic
growth of the buffer will not be supported; but code will be added to deal
robustly with overflowing Ack Vector buffers.
(b) A `tail_seqno' field. When naively implementing the algorithm of Appendix A
in RFC 4340, problems arise whenever subsequent Ack Vector records overlap,
which can bring the entire run length calculation completely out of synch.
(This is documented on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/\
ack_vectors/tracking_tail_ackno/ .)
(c) The buffer lengthi is now computed dynamically (i.e. current fill level),
as the span between head to tail.
As a result, dccp_ackvec_pending() is now simpler - the #ifdef is no longer
necessary since buf_empty is always true when IP_DCCP_ACKVEC is not configured.
Note on overflow handling:
-------------------------
The Ack Vector code previously simply started to drop packets when the
Ack Vector buffer overflowed. This means that the userspace application
will not be able to receive, only because of an Ack Vector storage problem.
Furthermore, overflow may be transient, so that applications may later
recover from the overflow. Recovering from dropped packets is more difficult
(e.g. video key frames).
Hence the patch uses a different policy: when the buffer overflows, the oldest
entries are subsequently overwritten. This has a higher chance of recovery.
Details are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ack_vectors/
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
av->av_buf_head = av->av_buf_tail = DCCPAV_MAX_ACKVEC_LEN - 1;
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
INIT_LIST_HEAD(&av->av_records);
|
|
|
|
}
|
|
|
|
return av;
|
|
|
|
}
|
2006-03-21 09:19:55 +08:00
|
|
|
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
static void dccp_ackvec_purge_records(struct dccp_ackvec *av)
|
|
|
|
{
|
|
|
|
struct dccp_ackvec_record *cur, *next;
|
2006-03-21 09:19:55 +08:00
|
|
|
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
list_for_each_entry_safe(cur, next, &av->av_records, avr_node)
|
|
|
|
kmem_cache_free(dccp_ackvec_record_slab, cur);
|
|
|
|
INIT_LIST_HEAD(&av->av_records);
|
2006-03-21 09:19:55 +08:00
|
|
|
}
|
|
|
|
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
void dccp_ackvec_free(struct dccp_ackvec *av)
|
2006-03-21 09:19:55 +08:00
|
|
|
{
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
if (likely(av != NULL)) {
|
|
|
|
dccp_ackvec_purge_records(av);
|
|
|
|
kmem_cache_free(dccp_ackvec_slab, av);
|
|
|
|
}
|
2006-03-21 09:19:55 +08:00
|
|
|
}
|
|
|
|
|
2008-09-04 13:30:19 +08:00
|
|
|
/**
|
|
|
|
* dccp_ackvec_update_records - Record information about sent Ack Vectors
|
|
|
|
* @av: Ack Vector records to update
|
|
|
|
* @seqno: Sequence number of the packet carrying the Ack Vector just sent
|
|
|
|
* @nonce_sum: The sum of all buffer nonces contained in the Ack Vector
|
|
|
|
*/
|
|
|
|
int dccp_ackvec_update_records(struct dccp_ackvec *av, u64 seqno, u8 nonce_sum)
|
2005-09-18 15:17:51 +08:00
|
|
|
{
|
2006-03-21 09:19:55 +08:00
|
|
|
struct dccp_ackvec_record *avr;
|
|
|
|
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
avr = kmem_cache_alloc(dccp_ackvec_record_slab, GFP_ATOMIC);
|
2006-03-21 14:32:06 +08:00
|
|
|
if (avr == NULL)
|
2008-09-04 13:30:19 +08:00
|
|
|
return -ENOBUFS;
|
2005-09-18 15:17:51 +08:00
|
|
|
|
2008-09-04 13:30:19 +08:00
|
|
|
avr->avr_ack_seqno = seqno;
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
avr->avr_ack_ptr = av->av_buf_head;
|
|
|
|
avr->avr_ack_ackno = av->av_buf_ackno;
|
2008-09-04 13:30:19 +08:00
|
|
|
avr->avr_ack_nonce = nonce_sum;
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
avr->avr_ack_runlen = dccp_ackvec_runlen(av->av_buf + av->av_buf_head);
|
dccp ccid-2: Implementation of circular Ack Vector buffer with overflow handling
This completes the implementation of a circular buffer for Ack Vectors, by
extending the current (linear array-based) implementation. The changes are:
(a) An `overflow' flag to deal with the case of overflow. As before, dynamic
growth of the buffer will not be supported; but code will be added to deal
robustly with overflowing Ack Vector buffers.
(b) A `tail_seqno' field. When naively implementing the algorithm of Appendix A
in RFC 4340, problems arise whenever subsequent Ack Vector records overlap,
which can bring the entire run length calculation completely out of synch.
(This is documented on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/\
ack_vectors/tracking_tail_ackno/ .)
(c) The buffer lengthi is now computed dynamically (i.e. current fill level),
as the span between head to tail.
As a result, dccp_ackvec_pending() is now simpler - the #ifdef is no longer
necessary since buf_empty is always true when IP_DCCP_ACKVEC is not configured.
Note on overflow handling:
-------------------------
The Ack Vector code previously simply started to drop packets when the
Ack Vector buffer overflowed. This means that the userspace application
will not be able to receive, only because of an Ack Vector storage problem.
Furthermore, overflow may be transient, so that applications may later
recover from the overflow. Recovering from dropped packets is more difficult
(e.g. video key frames).
Hence the patch uses a different policy: when the buffer overflows, the oldest
entries are subsequently overwritten. This has a higher chance of recovery.
Details are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ack_vectors/
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
/*
|
|
|
|
* When the buffer overflows, we keep no more than one record. This is
|
|
|
|
* the simplest way of disambiguating sender-Acks dating from before the
|
|
|
|
* overflow from sender-Acks which refer to after the overflow; a simple
|
|
|
|
* solution is preferable here since we are handling an exception.
|
|
|
|
*/
|
|
|
|
if (av->av_overflow)
|
|
|
|
dccp_ackvec_purge_records(av);
|
2008-09-04 13:30:19 +08:00
|
|
|
/*
|
|
|
|
* Since GSS is incremented for each packet, the list is automatically
|
|
|
|
* arranged in descending order of @ack_seqno.
|
|
|
|
*/
|
|
|
|
list_add(&avr->avr_node, &av->av_records);
|
2006-03-21 09:19:55 +08:00
|
|
|
|
2008-09-04 13:30:19 +08:00
|
|
|
dccp_pr_debug("Added Vector, ack_seqno=%llu, ack_ackno=%llu (rl=%u)\n",
|
2007-12-30 20:19:31 +08:00
|
|
|
(unsigned long long)avr->avr_ack_seqno,
|
2008-09-04 13:30:19 +08:00
|
|
|
(unsigned long long)avr->avr_ack_ackno,
|
|
|
|
avr->avr_ack_runlen);
|
2006-03-21 09:19:55 +08:00
|
|
|
return 0;
|
2005-09-18 15:17:51 +08:00
|
|
|
}
|
|
|
|
|
dccp ccid-2: Algorithm to update buffer state
This provides a routine to consistently update the buffer state when the
peer acknowledges receipt of Ack Vectors; updating state in the list of Ack
Vectors as well as in the circular buffer.
While based on RFC 4340, several additional (and necessary) precautions were
added to protect the consistency of the buffer state. These additions are
essential, since analysis and experience showed that the basic algorithm was
insufficient for this task (which lead to problems that were hard to debug).
The algorithm now
* deals with HC-sender acknowledging to HC-receiver and vice versa,
* keeps track of the last unacknowledged but received seqno in tail_ackno,
* has special cases to reset the overflow condition when appropriate,
* is protected against receiving older information (would mess up buffer state).
Note: The older code performed an unnecessary step, where the sender cleared
Ack Vector state by parsing the Ack Vector received by the HC-receiver. Doing
this was entirely redundant, since
* the receiver always puts the full acknowledgment window (groups 2,3 in 11.4.2)
into the Ack Vectors it sends; hence the HC-receiver is only interested in the
highest state that the HC-sender received;
* this means that the acknowledgment number on the (Data)Ack from the HC-sender
is sufficient; and work done in parsing earlier state is not necessary, since
the later state subsumes the earlier one (see also RFC 4340, A.4).
This older interface (dccp_ackvec_parse()) is therefore removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
static struct dccp_ackvec_record *dccp_ackvec_lookup(struct list_head *av_list,
|
|
|
|
const u64 ackno)
|
|
|
|
{
|
|
|
|
struct dccp_ackvec_record *avr;
|
|
|
|
/*
|
|
|
|
* Exploit that records are inserted in descending order of sequence
|
|
|
|
* number, start with the oldest record first. If @ackno is `before'
|
|
|
|
* the earliest ack_ackno, the packet is too old to be considered.
|
|
|
|
*/
|
|
|
|
list_for_each_entry_reverse(avr, av_list, avr_node) {
|
|
|
|
if (avr->avr_ack_seqno == ackno)
|
|
|
|
return avr;
|
|
|
|
if (before48(ackno, avr->avr_ack_seqno))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
dccp ccid-2: Implementation of circular Ack Vector buffer with overflow handling
This completes the implementation of a circular buffer for Ack Vectors, by
extending the current (linear array-based) implementation. The changes are:
(a) An `overflow' flag to deal with the case of overflow. As before, dynamic
growth of the buffer will not be supported; but code will be added to deal
robustly with overflowing Ack Vector buffers.
(b) A `tail_seqno' field. When naively implementing the algorithm of Appendix A
in RFC 4340, problems arise whenever subsequent Ack Vector records overlap,
which can bring the entire run length calculation completely out of synch.
(This is documented on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/\
ack_vectors/tracking_tail_ackno/ .)
(c) The buffer lengthi is now computed dynamically (i.e. current fill level),
as the span between head to tail.
As a result, dccp_ackvec_pending() is now simpler - the #ifdef is no longer
necessary since buf_empty is always true when IP_DCCP_ACKVEC is not configured.
Note on overflow handling:
-------------------------
The Ack Vector code previously simply started to drop packets when the
Ack Vector buffer overflowed. This means that the userspace application
will not be able to receive, only because of an Ack Vector storage problem.
Furthermore, overflow may be transient, so that applications may later
recover from the overflow. Recovering from dropped packets is more difficult
(e.g. video key frames).
Hence the patch uses a different policy: when the buffer overflows, the oldest
entries are subsequently overwritten. This has a higher chance of recovery.
Details are on http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/ack_vectors/
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
/*
|
|
|
|
* Buffer index and length computation using modulo-buffersize arithmetic.
|
|
|
|
* Note that, as pointers move from right to left, head is `before' tail.
|
|
|
|
*/
|
|
|
|
static inline u16 __ackvec_idx_add(const u16 a, const u16 b)
|
|
|
|
{
|
|
|
|
return (a + b) % DCCPAV_MAX_ACKVEC_LEN;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline u16 __ackvec_idx_sub(const u16 a, const u16 b)
|
|
|
|
{
|
|
|
|
return __ackvec_idx_add(a, DCCPAV_MAX_ACKVEC_LEN - b);
|
|
|
|
}
|
|
|
|
|
|
|
|
u16 dccp_ackvec_buflen(const struct dccp_ackvec *av)
|
|
|
|
{
|
|
|
|
if (unlikely(av->av_overflow))
|
|
|
|
return DCCPAV_MAX_ACKVEC_LEN;
|
|
|
|
return __ackvec_idx_sub(av->av_buf_tail, av->av_buf_head);
|
|
|
|
}
|
|
|
|
|
2008-09-04 13:30:19 +08:00
|
|
|
/**
|
|
|
|
* dccp_ackvec_update_old - Update previous state as per RFC 4340, 11.4.1
|
|
|
|
* @av: non-empty buffer to update
|
|
|
|
* @distance: negative or zero distance of @seqno from buf_ackno downward
|
|
|
|
* @seqno: the (old) sequence number whose record is to be updated
|
|
|
|
* @state: state in which packet carrying @seqno was received
|
|
|
|
*/
|
|
|
|
static void dccp_ackvec_update_old(struct dccp_ackvec *av, s64 distance,
|
|
|
|
u64 seqno, enum dccp_ackvec_states state)
|
|
|
|
{
|
|
|
|
u16 ptr = av->av_buf_head;
|
|
|
|
|
|
|
|
BUG_ON(distance > 0);
|
|
|
|
if (unlikely(dccp_ackvec_is_empty(av)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
do {
|
|
|
|
u8 runlen = dccp_ackvec_runlen(av->av_buf + ptr);
|
|
|
|
|
|
|
|
if (distance + runlen >= 0) {
|
|
|
|
/*
|
|
|
|
* Only update the state if packet has not been received
|
|
|
|
* yet. This is OK as per the second table in RFC 4340,
|
|
|
|
* 11.4.1; i.e. here we are using the following table:
|
|
|
|
* RECEIVED
|
|
|
|
* 0 1 3
|
|
|
|
* S +---+---+---+
|
|
|
|
* T 0 | 0 | 0 | 0 |
|
|
|
|
* O +---+---+---+
|
|
|
|
* R 1 | 1 | 1 | 1 |
|
|
|
|
* E +---+---+---+
|
|
|
|
* D 3 | 0 | 1 | 3 |
|
|
|
|
* +---+---+---+
|
|
|
|
* The "Not Received" state was set by reserve_seats().
|
|
|
|
*/
|
|
|
|
if (av->av_buf[ptr] == DCCPAV_NOT_RECEIVED)
|
|
|
|
av->av_buf[ptr] = state;
|
|
|
|
else
|
|
|
|
dccp_pr_debug("Not changing %llu state to %u\n",
|
|
|
|
(unsigned long long)seqno, state);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
distance += runlen + 1;
|
|
|
|
ptr = __ackvec_idx_add(ptr, 1);
|
|
|
|
|
|
|
|
} while (ptr != av->av_buf_tail);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Mark @num entries after buf_head as "Not yet received". */
|
|
|
|
static void dccp_ackvec_reserve_seats(struct dccp_ackvec *av, u16 num)
|
|
|
|
{
|
|
|
|
u16 start = __ackvec_idx_add(av->av_buf_head, 1),
|
|
|
|
len = DCCPAV_MAX_ACKVEC_LEN - start;
|
|
|
|
|
|
|
|
/* check for buffer wrap-around */
|
|
|
|
if (num > len) {
|
|
|
|
memset(av->av_buf + start, DCCPAV_NOT_RECEIVED, len);
|
|
|
|
start = 0;
|
|
|
|
num -= len;
|
|
|
|
}
|
|
|
|
if (num)
|
|
|
|
memset(av->av_buf + start, DCCPAV_NOT_RECEIVED, num);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dccp_ackvec_add_new - Record one or more new entries in Ack Vector buffer
|
|
|
|
* @av: container of buffer to update (can be empty or non-empty)
|
|
|
|
* @num_packets: number of packets to register (must be >= 1)
|
|
|
|
* @seqno: sequence number of the first packet in @num_packets
|
|
|
|
* @state: state in which packet carrying @seqno was received
|
|
|
|
*/
|
|
|
|
static void dccp_ackvec_add_new(struct dccp_ackvec *av, u32 num_packets,
|
|
|
|
u64 seqno, enum dccp_ackvec_states state)
|
|
|
|
{
|
|
|
|
u32 num_cells = num_packets;
|
|
|
|
|
|
|
|
if (num_packets > DCCPAV_BURST_THRESH) {
|
|
|
|
u32 lost_packets = num_packets - 1;
|
|
|
|
|
|
|
|
DCCP_WARN("Warning: large burst loss (%u)\n", lost_packets);
|
|
|
|
/*
|
|
|
|
* We received 1 packet and have a loss of size "num_packets-1"
|
|
|
|
* which we squeeze into num_cells-1 rather than reserving an
|
|
|
|
* entire byte for each lost packet.
|
|
|
|
* The reason is that the vector grows in O(burst_length); when
|
|
|
|
* it grows too large there will no room left for the payload.
|
|
|
|
* This is a trade-off: if a few packets out of the burst show
|
|
|
|
* up later, their state will not be changed; it is simply too
|
|
|
|
* costly to reshuffle/reallocate/copy the buffer each time.
|
|
|
|
* Should such problems persist, we will need to switch to a
|
|
|
|
* different underlying data structure.
|
|
|
|
*/
|
|
|
|
for (num_packets = num_cells = 1; lost_packets; ++num_cells) {
|
|
|
|
u8 len = min(lost_packets, (u32)DCCPAV_MAX_RUNLEN);
|
|
|
|
|
|
|
|
av->av_buf_head = __ackvec_idx_sub(av->av_buf_head, 1);
|
|
|
|
av->av_buf[av->av_buf_head] = DCCPAV_NOT_RECEIVED | len;
|
|
|
|
|
|
|
|
lost_packets -= len;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (num_cells + dccp_ackvec_buflen(av) >= DCCPAV_MAX_ACKVEC_LEN) {
|
|
|
|
DCCP_CRIT("Ack Vector buffer overflow: dropping old entries\n");
|
|
|
|
av->av_overflow = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
av->av_buf_head = __ackvec_idx_sub(av->av_buf_head, num_packets);
|
|
|
|
if (av->av_overflow)
|
|
|
|
av->av_buf_tail = av->av_buf_head;
|
|
|
|
|
|
|
|
av->av_buf[av->av_buf_head] = state;
|
|
|
|
av->av_buf_ackno = seqno;
|
|
|
|
|
|
|
|
if (num_packets > 1)
|
|
|
|
dccp_ackvec_reserve_seats(av, num_packets - 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* dccp_ackvec_input - Register incoming packet in the buffer
|
|
|
|
*/
|
|
|
|
void dccp_ackvec_input(struct dccp_ackvec *av, struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
u64 seqno = DCCP_SKB_CB(skb)->dccpd_seq;
|
|
|
|
enum dccp_ackvec_states state = DCCPAV_RECEIVED;
|
|
|
|
|
|
|
|
if (dccp_ackvec_is_empty(av)) {
|
|
|
|
dccp_ackvec_add_new(av, 1, seqno, state);
|
|
|
|
av->av_tail_ackno = seqno;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
s64 num_packets = dccp_delta_seqno(av->av_buf_ackno, seqno);
|
|
|
|
u8 *current_head = av->av_buf + av->av_buf_head;
|
|
|
|
|
|
|
|
if (num_packets == 1 &&
|
|
|
|
dccp_ackvec_state(current_head) == state &&
|
|
|
|
dccp_ackvec_runlen(current_head) < DCCPAV_MAX_RUNLEN) {
|
|
|
|
|
|
|
|
*current_head += 1;
|
|
|
|
av->av_buf_ackno = seqno;
|
|
|
|
|
|
|
|
} else if (num_packets > 0) {
|
|
|
|
dccp_ackvec_add_new(av, num_packets, seqno, state);
|
|
|
|
} else {
|
|
|
|
dccp_ackvec_update_old(av, num_packets, seqno, state);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
dccp ccid-2: Algorithm to update buffer state
This provides a routine to consistently update the buffer state when the
peer acknowledges receipt of Ack Vectors; updating state in the list of Ack
Vectors as well as in the circular buffer.
While based on RFC 4340, several additional (and necessary) precautions were
added to protect the consistency of the buffer state. These additions are
essential, since analysis and experience showed that the basic algorithm was
insufficient for this task (which lead to problems that were hard to debug).
The algorithm now
* deals with HC-sender acknowledging to HC-receiver and vice versa,
* keeps track of the last unacknowledged but received seqno in tail_ackno,
* has special cases to reset the overflow condition when appropriate,
* is protected against receiving older information (would mess up buffer state).
Note: The older code performed an unnecessary step, where the sender cleared
Ack Vector state by parsing the Ack Vector received by the HC-receiver. Doing
this was entirely redundant, since
* the receiver always puts the full acknowledgment window (groups 2,3 in 11.4.2)
into the Ack Vectors it sends; hence the HC-receiver is only interested in the
highest state that the HC-sender received;
* this means that the acknowledgment number on the (Data)Ack from the HC-sender
is sufficient; and work done in parsing earlier state is not necessary, since
the later state subsumes the earlier one (see also RFC 4340, A.4).
This older interface (dccp_ackvec_parse()) is therefore removed.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
/**
|
|
|
|
* dccp_ackvec_clear_state - Perform house-keeping / garbage-collection
|
|
|
|
* This routine is called when the peer acknowledges the receipt of Ack Vectors
|
|
|
|
* up to and including @ackno. While based on on section A.3 of RFC 4340, here
|
|
|
|
* are additional precautions to prevent corrupted buffer state. In particular,
|
|
|
|
* we use tail_ackno to identify outdated records; it always marks the earliest
|
|
|
|
* packet of group (2) in 11.4.2.
|
|
|
|
*/
|
|
|
|
void dccp_ackvec_clear_state(struct dccp_ackvec *av, const u64 ackno)
|
|
|
|
{
|
|
|
|
struct dccp_ackvec_record *avr, *next;
|
|
|
|
u8 runlen_now, eff_runlen;
|
|
|
|
s64 delta;
|
|
|
|
|
|
|
|
avr = dccp_ackvec_lookup(&av->av_records, ackno);
|
|
|
|
if (avr == NULL)
|
|
|
|
return;
|
|
|
|
/*
|
|
|
|
* Deal with outdated acknowledgments: this arises when e.g. there are
|
|
|
|
* several old records and the acks from the peer come in slowly. In
|
|
|
|
* that case we may still have records that pre-date tail_ackno.
|
|
|
|
*/
|
|
|
|
delta = dccp_delta_seqno(av->av_tail_ackno, avr->avr_ack_ackno);
|
|
|
|
if (delta < 0)
|
|
|
|
goto free_records;
|
|
|
|
/*
|
|
|
|
* Deal with overlapping Ack Vectors: don't subtract more than the
|
|
|
|
* number of packets between tail_ackno and ack_ackno.
|
|
|
|
*/
|
|
|
|
eff_runlen = delta < avr->avr_ack_runlen ? delta : avr->avr_ack_runlen;
|
|
|
|
|
|
|
|
runlen_now = dccp_ackvec_runlen(av->av_buf + avr->avr_ack_ptr);
|
|
|
|
/*
|
|
|
|
* The run length of Ack Vector cells does not decrease over time. If
|
|
|
|
* the run length is the same as at the time the Ack Vector was sent, we
|
|
|
|
* free the ack_ptr cell. That cell can however not be freed if the run
|
|
|
|
* length has increased: in this case we need to move the tail pointer
|
|
|
|
* backwards (towards higher indices), to its next-oldest neighbour.
|
|
|
|
*/
|
|
|
|
if (runlen_now > eff_runlen) {
|
|
|
|
|
|
|
|
av->av_buf[avr->avr_ack_ptr] -= eff_runlen + 1;
|
|
|
|
av->av_buf_tail = __ackvec_idx_add(avr->avr_ack_ptr, 1);
|
|
|
|
|
|
|
|
/* This move may not have cleared the overflow flag. */
|
|
|
|
if (av->av_overflow)
|
|
|
|
av->av_overflow = (av->av_buf_head == av->av_buf_tail);
|
|
|
|
} else {
|
|
|
|
av->av_buf_tail = avr->avr_ack_ptr;
|
|
|
|
/*
|
|
|
|
* We have made sure that avr points to a valid cell within the
|
|
|
|
* buffer. This cell is either older than head, or equals head
|
|
|
|
* (empty buffer): in both cases we no longer have any overflow.
|
|
|
|
*/
|
|
|
|
av->av_overflow = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The peer has acknowledged up to and including ack_ackno. Hence the
|
|
|
|
* first packet in group (2) of 11.4.2 is the successor of ack_ackno.
|
|
|
|
*/
|
|
|
|
av->av_tail_ackno = ADD48(avr->avr_ack_ackno, 1);
|
|
|
|
|
|
|
|
free_records:
|
|
|
|
list_for_each_entry_safe_from(avr, next, &av->av_records, avr_node) {
|
|
|
|
list_del(&avr->avr_node);
|
|
|
|
kmem_cache_free(dccp_ackvec_record_slab, avr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-09-04 13:30:19 +08:00
|
|
|
/*
|
|
|
|
* Routines to keep track of Ack Vectors received in an skb
|
|
|
|
*/
|
|
|
|
int dccp_ackvec_parsed_add(struct list_head *head, u8 *vec, u8 len, u8 nonce)
|
|
|
|
{
|
|
|
|
struct dccp_ackvec_parsed *new = kmalloc(sizeof(*new), GFP_ATOMIC);
|
|
|
|
|
|
|
|
if (new == NULL)
|
|
|
|
return -ENOBUFS;
|
|
|
|
new->vec = vec;
|
|
|
|
new->len = len;
|
|
|
|
new->nonce = nonce;
|
|
|
|
|
|
|
|
list_add_tail(&new->node, head);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dccp_ackvec_parsed_add);
|
|
|
|
|
|
|
|
void dccp_ackvec_parsed_cleanup(struct list_head *parsed_chunks)
|
|
|
|
{
|
|
|
|
struct dccp_ackvec_parsed *cur, *next;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(cur, next, parsed_chunks, node)
|
|
|
|
kfree(cur);
|
|
|
|
INIT_LIST_HEAD(parsed_chunks);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dccp_ackvec_parsed_cleanup);
|
|
|
|
|
2006-03-21 09:16:17 +08:00
|
|
|
int __init dccp_ackvec_init(void)
|
|
|
|
{
|
|
|
|
dccp_ackvec_slab = kmem_cache_create("dccp_ackvec",
|
|
|
|
sizeof(struct dccp_ackvec), 0,
|
2007-07-20 09:11:58 +08:00
|
|
|
SLAB_HWCACHE_ALIGN, NULL);
|
2006-03-21 09:19:55 +08:00
|
|
|
if (dccp_ackvec_slab == NULL)
|
|
|
|
goto out_err;
|
|
|
|
|
dccp ccid-2: Ack Vector interface clean-up
This patch brings the Ack Vector interface up to date. Its main purpose is
to lay the basis for the subsequent patches of this set, which will use the
new data structure fields and routines.
There are no real algorithmic changes, rather an adaptation:
(1) Replaced the static Ack Vector size (2) with a #define so that it can
be adapted (with low loss / Ack Ratio, a value of 1 works, so 2 seems
to be sufficient for the moment) and added a solution so that computing
the ECN nonce will continue to work - even with larger Ack Vectors.
(2) Replaced the #defines for Ack Vector states with a complete enum.
(3) Replaced #defines to compute Ack Vector length and state with general
purpose routines (inlines), and updated code to use these.
(4) Added a `tail' field (conversion to circular buffer in subsequent patch).
(5) Updated the (outdated) documentation for Ack Vector struct.
(6) All sequence number containers now trimmed to 48 bits.
(7) Removal of unused bits:
* removed dccpav_ack_nonce from struct dccp_ackvec, since this is already
redundantly stored in the `dccpavr_ack_nonce' (of Ack Vector record);
* removed Elapsed Time for Ack Vectors (it was nowhere used);
* replaced semantics of dccpavr_sent_len with dccpavr_ack_runlen, since
the code needs to be able to remember the old run length;
* reduced the de-/allocation routines (redundant / duplicate tests).
Justification for removing Elapsed Time information [can be removed]:
---------------------------------------------------------------------
1. The Elapsed Time information for Ack Vectors was nowhere used in the code.
2. DCCP does not implement rate-based pacing of acknowledgments. The only
recommendation for always including Elapsed Time is in section 11.3 of
RFC 4340: "Receivers that rate-pace acknowledgements SHOULD [...]
include Elapsed Time options". But such is not the case here.
3. It does not really improve estimation accuracy. The Elapsed Time field only
records the time between the arrival of the last acknowledgeable packet and
the time the Ack Vector is sent out. Since Linux does not (yet) implement
delayed Acks, the time difference will typically be small, since often the
arrival of a data packet triggers sending feedback at the HC-receiver.
Justification for changes in de-/allocation routines [can be removed]:
----------------------------------------------------------------------
* INIT_LIST_HEAD in dccp_ackvec_record_new was redundant, since the list
pointers were later overwritten when the node was added via list_add();
* dccp_ackvec_record_new() was called in a single place only;
* calls to list_del_init() before calling dccp_ackvec_record_delete() were
redundant, since subsequently the entire element was k-freed;
* since all calls to dccp_ackvec_record_delete() were preceded to a call to
list_del_init(), the WARN_ON test would never evaluate to true;
* since all calls to dccp_ackvec_record_delete() were made from within
list_for_each_entry_safe(), the test for avr == NULL was redundant;
* list_empty() in ackvec_free was redundant, since the same condition is
embedded in the loop condition of the subsequent list_for_each_entry_safe().
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
2008-09-04 13:30:19 +08:00
|
|
|
dccp_ackvec_record_slab = kmem_cache_create("dccp_ackvec_record",
|
|
|
|
sizeof(struct dccp_ackvec_record),
|
|
|
|
0, SLAB_HWCACHE_ALIGN, NULL);
|
2006-03-21 09:19:55 +08:00
|
|
|
if (dccp_ackvec_record_slab == NULL)
|
|
|
|
goto out_destroy_slab;
|
2006-03-21 09:16:17 +08:00
|
|
|
|
|
|
|
return 0;
|
2006-03-21 09:19:55 +08:00
|
|
|
|
|
|
|
out_destroy_slab:
|
|
|
|
kmem_cache_destroy(dccp_ackvec_slab);
|
|
|
|
dccp_ackvec_slab = NULL;
|
|
|
|
out_err:
|
2006-11-21 04:39:23 +08:00
|
|
|
DCCP_CRIT("Unable to create Ack Vector slab cache");
|
2006-03-21 09:19:55 +08:00
|
|
|
return -ENOBUFS;
|
2006-03-21 09:16:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void dccp_ackvec_exit(void)
|
|
|
|
{
|
|
|
|
if (dccp_ackvec_slab != NULL) {
|
|
|
|
kmem_cache_destroy(dccp_ackvec_slab);
|
|
|
|
dccp_ackvec_slab = NULL;
|
|
|
|
}
|
2006-03-21 09:19:55 +08:00
|
|
|
if (dccp_ackvec_record_slab != NULL) {
|
|
|
|
kmem_cache_destroy(dccp_ackvec_record_slab);
|
|
|
|
dccp_ackvec_record_slab = NULL;
|
|
|
|
}
|
2006-03-21 09:16:17 +08:00
|
|
|
}
|