1. 26 9月, 2015 1 次提交
  2. 24 3月, 2015 1 次提交
  3. 21 3月, 2015 1 次提交
  4. 03 3月, 2015 1 次提交
  5. 09 11月, 2014 1 次提交
  6. 05 1月, 2014 1 次提交
  7. 20 10月, 2013 1 次提交
  8. 11 7月, 2012 1 次提交
  9. 16 4月, 2012 1 次提交
  10. 20 12月, 2011 1 次提交
  11. 12 12月, 2011 1 次提交
  12. 01 8月, 2011 1 次提交
    • G
      dccp: support for the exchange of NN options in established state 1/2 · d6916f87
      Gerrit Renker 提交于
      In contrast to static feature negotiation at the begin of a connection, this
      patch introduces support for exchange of dynamically changing options.
      
      Such an update/exchange is necessary in at least two cases:
       * CCID-2's Ack Ratio (RFC 4341, 6.1.2) which changes during the connection;
       * Sequence Window values that, as per RFC 4340, 7.5.2, should be sent "as
         the connection progresses".
      
      Both are non-negotiable (NN) features, which means that no new capabilities
      are negotiated, but rather that changes in known parameters are brought
      up-to-date at either end.
      
      Thse characteristics are reflected by the implementation:
       * only NN options can be exchanged after connection setup;
       * an ack is scheduled directly after activation to speed up the update;
       * CCIDs may request changes to an NN feature even if a negotiation for that
         feature is already underway: this is required by CCID-2, where changes in
         cwnd necessitate Ack Ratio changes, such that the previous Ack Ratio (which
         is still being negotiated) would cause irrecoverable RTO timeouts (thanks
         to work by Samuel Jero).	   
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NSamuel Jero <sj323707@ohio.edu>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.uk>
      d6916f87
  13. 07 1月, 2011 1 次提交
  14. 10 12月, 2010 1 次提交
  15. 07 12月, 2010 2 次提交
  16. 11 11月, 2010 1 次提交
    • G
      dccp ccid-2: Implementation of circular Ack Vector buffer with overflow handling · b3d14bff
      Gerrit Renker 提交于
      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 length 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.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      b3d14bff
  17. 29 10月, 2010 1 次提交
    • G
      dccp: Refine the wait-for-ccid mechanism · b1fcf55e
      Gerrit Renker 提交于
      This extends the existing wait-for-ccid routine so that it may be used with
      different types of CCID, addressing the following problems:
      
       1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for
          example has a full TX queue and becomes network-limited just as the
          application wants to close, then waiting for CCID-2 to become unblocked
          could lead to an indefinite  delay (i.e., application "hangs").
       2) Since each TX CCID in turn uses a feedback mechanism, there may be changes
          in its sending policy while the queue is being drained. This can lead to
          further delays during which the application will not be able to terminate.
       3) The minimum wait time for CCID-3/4 can be expected to be the queue length
          times the current inter-packet delay. For example if tx_qlen=100 and a delay
          of 15 ms is used for each packet, then the application would have to wait
          for a minimum of 1.5 seconds before being allowed to exit.
       4) There is no way for the user/application to control this behaviour. It would
          be good to use the timeout argument of dccp_close() as an upper bound. Then
          the maximum time that an application is willing to wait for its CCIDs to can
          be set via the SO_LINGER option.
      
      These problems are addressed by giving the CCID a grace period of up to the
      `timeout' value.
      
      The wait-for-ccid function is, as before, used when the application
       (a) has read all the data in its receive buffer and
       (b) if SO_LINGER was set with a non-zero linger time, or
       (c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ
           state (client application closes after receiving CloseReq).
      
      In addition, there is a catch-all case of __skb_queue_purge() after waiting for
      the CCID. This is necessary since the write queue may still have data when
       (a) the host has been passively-closed,
       (b) abnormal termination (unread data, zero linger time),
       (c) wait-for-ccid could not finish within the given time limit.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b1fcf55e
  18. 12 10月, 2010 3 次提交
    • G
      dccp: schedule an Ack when receiving timestamps · ecdfbdab
      Gerrit Renker 提交于
      This schedules an Ack when receiving a timestamp, exploiting the
      existing inet_csk_schedule_ack() function, saving one case in the
      `dccp_ack_pending()' function.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      ecdfbdab
    • I
      dccp: generalise data-loss condition · d196c9a5
      Ivo Calado 提交于
      This patch generalises the task of determining data loss from RFC 4340, 7.7.1.
      
      Let S_A, S_B be sequence numbers such that S_B is "after" S_A, and let
      N_B be the NDP count of packet S_B. Then, using modulo-2^48 arithmetic,
       D = S_B - S_A - 1  is an upper bound of the number of lost data packets,
       D - N_B            is an approximation of the number of lost data packets
                          (there are cases where this is not exact).
      
      The patch implements this as
       dccp_loss_count(S_A, S_B, N_B) := max(S_B - S_A - 1 - N_B, 0)
      Signed-off-by: NIvo Calado <ivocalado@embedded.ufcg.edu.br>
      Signed-off-by: NErivaldo Xavier <desadoc@gmail.com>
      Signed-off-by: NLeandro Sales <leandroal@gmail.com>
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      d196c9a5
    • G
      dccp: fix the adjustments to AWL and SWL · 0b53d460
      Gerrit Renker 提交于
      This fixes a problem and a potential loophole with regard to seqno/ackno
      validity: currently the initial adjustments to AWL/SWL are only performed
      once at the begin of the connection, during the handshake.
      
      Since the Sequence Window feature is always greater than Wmin=32 (7.5.2),
      it is however necessary to perform these adjustments at least for the first
      W/W' (variables as per 7.5.1) packets in the lifetime of a connection.
      
      This requirement is complicated by the fact that W/W' can change at any time
      during the lifetime of a connection.
      
      Therefore it is better to perform that safety check each time SWL/AWL are
      updated, as implemented by the patch.
      
      A second problem solved by this patch is that the remote/local Sequence Window
      feature values (which set the bounds for AWL/SWL/SWH) are undefined until the
      feature negotiation has completed.
      
      During the initial handshake we have more stringent sequence number protection;
      the changes added by this patch effect that {A,S}W{L,H} are within the correct
      bounds at the instant that feature negotiation completes (since the SeqWin
      feature activation handlers call dccp_update_gsr/gss()).
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      0b53d460
  19. 07 10月, 2010 1 次提交
  20. 26 6月, 2010 1 次提交
  21. 12 4月, 2010 1 次提交
  22. 22 3月, 2010 1 次提交
  23. 01 10月, 2009 1 次提交
  24. 02 3月, 2009 1 次提交
    • G
      dccp: Do not let initial option overhead shrink the MPS · 86739fb9
      Gerrit Renker 提交于
      This fixes a problem caused by the overlap of the connection-setup and
      established-state phases of DCCP connections.
      
      During connection setup, the client retransmits Confirm Feature-Negotiation
      options until a response from the server signals that it can move from the
      half-established PARTOPEN into the OPEN state, whereupon the connection is
      fully established on both ends (RFC 4340, 8.1.5).
      
      However, since the client may already send data while it is in the PARTOPEN
      state, consequences arise for the Maximum Packet Size: the problem is that the
      initial option overhead is much higher than for the subsequent established
      phase, as it involves potentially many variable-length list-type options
      (server-priority options, RFC 4340, 6.4).
      
      Applying the standard MPS is insufficient here: especially with larger
      payloads this can lead to annoying, counter-intuitive EMSGSIZE errors.
      
      On the other hand, reducing the MPS available for the established phase by
      the added initial overhead is highly wasteful and inefficient.
      
      The solution chosen therefore is a two-phase strategy:
      
         If the payload length of the DataAck in PARTOPEN is too large, an Ack is sent
         to carry the options, and the feature-negotiation list is then flushed.
      
         This means that the server gets two Acks for one Response. If both Acks get
         lost, it is probably better to restart the connection anyway and devising yet
         another special-case does not seem worth the extra complexity.
      
      The result is a higher utilisation of the available packet space for the data
      transmission phase (established state) of a connection.
      
      The patch (over-)estimates the initial overhead to be 32*4 bytes -- commonly
      seen values were around 90 bytes for initial feature-negotiation options.
      
      It uses sizeof(u32) to mean "aligned units of 4 bytes".
      For consistency, another use of 4-byte alignment is adapted.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86739fb9
  25. 22 1月, 2009 3 次提交
    • G
      dccp: Debugging functions for feature negotiation · f3f3abb6
      Gerrit Renker 提交于
      Since all feature-negotiation processing now takes place in feat.c,
      functions for producing verbose debugging output are concentrated
      there.
      
      New functions to print out values, entry records, and options are
      provided, and also a macro is defined to not always have the function
      name in the output line.
      
      Thanks a lot to Wei Yongjun and Giuseppe Galeota for help and
      discussion with an earlier revision of this patch.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f3f3abb6
    • G
      dccp: Initialisation and type-checking of feature sysctls · 883ca833
      Gerrit Renker 提交于
      This patch takes care of initialising and type-checking sysctls
      related to feature negotiation. Type checking is important since some
      of the sysctls now directly impact the feature-negotiation process.
      
      The sysctls are initialised with the known default values for each
      feature.  For the type-checking the value constraints from RFC 4340
      are used:
      
       * Sequence Window uses the specified Wmin=32, the maximum is ulong (4 bytes),
         tested and confirmed that it works up to 4294967295 - for Gbps speed;
       * Ack Ratio is between 0 .. 0xffff (2-byte unsigned integer);
       * CCIDs are between 0 .. 255;
       * request_retries, retries1, retries2 also between 0..255 for good measure;
       * tx_qlen is checked to be non-negative;
       * sync_ratelimit remains as before.
      
      Notes:
      ------
       1. Die s@sysctl_dccp_feat@sysctl_dccp@g since the sysctls are now in feat.c.
       2. As pointed out by Arnaldo, the pattern of type-checking repeats itself in
          other places, sometimes with exactly the same kind of definitions (e.g.
          "static int zero;"). It may be a good idea (kernel janitors?) to consolidate
          type checking. For the sake of keeping the changeset small and in order not
          to affect other subsystems, I have not strived to generalise here.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      883ca833
    • G
      dccp: Implement both feature-local and feature-remote Sequence Window feature · 792b4878
      Gerrit Renker 提交于
      This adds full support for local/remote Sequence Window feature, from which the
        * sequence-number-validity (W) and
        * acknowledgment-number-validity (W') windows
      derive as specified in RFC 4340, 7.5.3.
      
      Specifically, the following is contained in this patch:
        * integrated new socket fields into dccp_sk;
        * updated the update_gsr/gss routines with regard to these fields;
        * updated handler code: the Sequence Window feature is located at the TX side,
          so the local feature is meant if the handler-rx flag is false;
        * the initialisation of `rcv_wnd' in reqsk is removed, since
          - rcv_wnd is not used by the code anywhere;
          - sequence number checks are not done in the LISTEN state (cf. 7.5.3);
          - dccp_check_req checks the Ack number validity more rigorously;
        * the `struct dccp_minisock' became empty and is now removed.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      792b4878
  26. 05 1月, 2009 1 次提交
    • G
      dccp: Lockless integration of CCID congestion-control plugins · ddebc973
      Gerrit Renker 提交于
      Based on Arnaldo's earlier patch, this patch integrates the standardised
      CCID congestion control plugins (CCID-2 and CCID-3) of DCCP with dccp.ko:
      
       * enables a faster connection path by eliminating the need to always go 
         through the CCID registration lock;
      
       * updates the implementation to use only a single array whose size equals
         the number of configured CCIDs instead of the maximum (256);
      
       * since the CCIDs are now fixed array elements, synchronization is no
         longer needed, simplifying use and implementation.
      
      CCID-2 is suggested as minimum for a basic DCCP implementation (RFC 4340, 10);
      CCID-3 is a standards-track CCID supported by RFC 4342 and RFC 5348.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddebc973
  27. 08 12月, 2008 2 次提交
    • G
      dccp ccid-2: Phase out the use of boolean Ack Vector sysctl · 6fdd34d4
      Gerrit Renker 提交于
      This removes the use of the sysctl and the minisock variable for the Send Ack
      Vector feature, as it now is handled fully dynamically via feature negotiation
      (i.e. when CCID-2 is enabled, Ack Vectors are automatically enabled as per
       RFC 4341, 4.).
      
      Using a sysctl in parallel to this implementation would open the door to
      crashes, since much of the code relies on tests of the boolean minisock /
      sysctl variable. Thus, this patch replaces all tests of type
      
      	if (dccp_msk(sk)->dccpms_send_ack_vector)
      		/* ... */
      with
      	if (dp->dccps_hc_rx_ackvec != NULL)
      		/* ... */
      
      The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature
      negotiation concluded that Ack Vectors are to be used on the half-connection.
      Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child),
      so that the test is a valid one.
      
      The activation handler for Ack Vectors is called as soon as the feature
      negotiation has concluded at the
       * server when the Ack marking the transition RESPOND => OPEN arrives;
       * client after it has sent its ACK, marking the transition REQUEST => PARTOPEN.
      
      Adding the sequence number of the Response packet to the Ack Vector has been
      removed, since
       (a) connection establishment implies that the Response has been received;
       (b) the CCIDs only look at packets received in the (PART)OPEN state, i.e.
           this entry will always be ignored;
       (c) it can not be used for anything useful - to detect loss for instance, only
           packets received after the loss can serve as pseudo-dupacks.
      
      There was a FIXME to change the error code when dccp_ackvec_add() fails.
      I removed this after finding out that:
       * the check whether ackno < ISN is already made earlier,
       * this Response is likely the 1st packet with an Ackno that the client gets,
       * so when dccp_ackvec_add() fails, the reason is likely not a packet error.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6fdd34d4
    • G
      dccp: Remove manual influence on NDP Count feature · 4098dce5
      Gerrit Renker 提交于
      Updating the NDP count feature is handled automatically now:
       * for CCID-2 it is disabled, since the code does not use NDP counts;
       * for CCID-3 it is enabled, as NDP counts are used to determine loss lengths.
      
      Allowing the user to change NDP values leads to unpredictable and failing
      behaviour, since it is then possible to disable NDP counts even when they
      are needed (e.g. in CCID-3).
      
      This means that only those user settings are sensible that agree with the
      values for Send NDP Count implied by the choice of CCID. But those settings
      are already activated by the feature negotiation (CCID dependency tracking),
      hence this form of support is redundant.
      
      At startup the initialisation of the NDP count feature uses the default
      value of 0, which is done implicitly by the zeroing-out of the socket when
      it is allocated. If the choice of CCID or feature negotiation enables NDP
      count, this will then be updated via the NDP activation handler.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4098dce5
  28. 02 12月, 2008 2 次提交
  29. 26 11月, 2008 1 次提交
  30. 17 11月, 2008 2 次提交
    • G
      dccp: Deprecate Ack Ratio sysctl · dd9c0e36
      Gerrit Renker 提交于
      This patch deprecates the Ack Ratio sysctl, since
       * Ack Ratio is entirely ignored by CCID-3 and CCID-4,
       * Ack Ratio currently doesn't work in CCID-2 (i.e. is always set to 1);
       * even if it would work in CCID-2, there is no point for a user to change it:
         - Ack Ratio is constrained by cwnd (RFC 4341, 6.1.2),
         - if Ack Ratio > cwnd, the system resorts to spurious RTO timeouts
           (since waiting for Acks which will never arrive in this window),
         - cwnd is not a user-configurable value.
      
      The only reasonable place for Ack Ratio is to print it for debugging. It is
      planned to do this later on, as part of e.g. dccp_probe.
      
      With this patch Ack Ratio is now under full control of feature negotiation:
       * Ack Ratio is resolved as a dependency of the selected CCID;
       * if the chosen CCID supports it (i.e. CCID == CCID-2), Ack Ratio is set to
         the default of 2, following RFC 4340, 11.3 - "New connections start with Ack
         Ratio 2 for both endpoints";
       * what happens then is part of another patch set, since it concerns the
         dynamic update of Ack Ratio while the connection is in full flight.
      
      Thanks to Tomasz Grobelny for discussion leading up to this patch.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd9c0e36
    • G
      dccp: Mechanism to resolve CCID dependencies · 0c116839
      Gerrit Renker 提交于
      This adds a hook to resolve features whose value depends on the choice of
      CCID. It is done at the server since it can only be done after the CCID
      values have been negotiated; i.e. the client will add its CCID preference
      list on the Change options sent in the Request, which will be reconciled
      with the local preference list of the server.
      
      The concept is documented on
      http://www.erg.abdn.ac.uk/users/gerrit/dccp/notes/feature_negotiation/\
      				implementation_notes.html#ccid_dependencies
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c116839
  31. 12 11月, 2008 1 次提交
    • G
      dccp: Resolve dependencies of features on choice of CCID · 9eca0a47
      Gerrit Renker 提交于
      This provides a missing link in the code chain, as several features implicitly
      depend and/or rely on the choice of CCID. Most notably, this is the Send Ack Vector
      feature, but also Ack Ratio and Send Loss Event Rate (also taken care of).
      
      For Send Ack Vector, the situation is as follows:
       * since CCID2 mandates the use of Ack Vectors, there is no point in allowing 
         endpoints which use CCID2 to disable Ack Vector features such a connection;
      
       * a peer with a TX CCID of CCID2 will always expect Ack Vectors, and a peer
         with a RX CCID of CCID2 must always send Ack Vectors (RFC 4341, sec. 4);
      
       * for all other CCIDs, the use of (Send) Ack Vector is optional and thus
         negotiable. However, this implies that the code negotiating the use of Ack
         Vectors also supports it (i.e. is able to supply and to either parse or
         ignore received Ack Vectors). Since this is not the case (CCID-3 has no Ack
         Vector support), the use of Ack Vectors is here disabled, with a comment
         in the source code.
      
      An analogous consideration arises for the Send Loss Event Rate feature,
      since the CCID-3 implementation does not support the loss interval options
      of RFC 4342. To make such use explicit, corresponding feature-negotiation
      options are inserted which signal the use of the loss event rate option,
      as it is used by the CCID3 code.
      
      Lastly, the values of the Ack Ratio feature are matched to the choice of CCID.
      
      The patch implements this as a function which is called after the user has
      made all other registrations for changing default values of features.
      
      The table is variable-length, the reserved (and hence for feature-negotiation
      invalid, confirmed by considering section 19.4 of RFC 4340) feature number `0'
      is used to mark the end of the table.
      Signed-off-by: NGerrit Renker <gerrit@erg.abdn.ac.uk>
      Acked-by: NIan McDonald <ian.mcdonald@jandi.co.nz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9eca0a47
  32. 05 11月, 2008 1 次提交