Re: [PATCH v2 4/9]: Resolve dependencies of features on choice of CCID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/3/07, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> wrote:
> ------------------------------> Patch v2 <-----------------------------------------
> [DCCP]: Resolve dependencies of features on choice of CCID
>
> 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 the patch also takes care of Ack Ratio and Send Loss Event Rate.
>
> 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 Send Ack Vector features on the corresponding half-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 (CCID3 has no Ack Vector support), the use of Ack Vectors is here disabled, with a
>    corresponding comment in the source code.
>
> An analogous consideration arises for the Send Loss Event Rate feature, since the CCID3
> 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 of 0 is used to mark the end of the table.
>
> Signed-off-by: Gerrit Renker <gerrit@xxxxxxxxxxxxxx>

Acked-by: Ian McDonald <ian.mcdonald@xxxxxxxxxxx>

(I have seen Arnaldo's/your later correspondence and happy enough that
you'll resolve that)
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [IETF DCCP]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux