Re: [PATCH 01/07] dccp: support for the exchange of NN options in established state 1/2

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

 



You have my signed-off-by for this patch.

I'm not clear if you intend to use this top commit message for the
entire patch, if so, see comment below.

> In contrast to static feature negotiation at the begin of a connection, which
> establishes the capabilities of both endpoints, this patch introduces support
> for dynamic exchange of feature negotiation options.
> 
> Such a dynamic 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
>    as the connection progresses".
> 
> Both are NN (non-negotiable) features. Hence dynamic feature "negotiation" is
> distinguished from static/pre-connection negotiation by the following:
>  * no new capabilities are negotiated (those that matter for the connection
>    are negotiated prior to setting up the connection, comparable to SIP);
>  * features must be understood by each endpoint: as per RFC 4340, 6.4,
>    Sequence Window is "Req'd" and Ack Ratio must be understood when CCID-2
>    is used as per the note underneath Table 4.
> 
> These characteristics are reflected in the implementation:
>  * only NN options can be exchanged after connection setup;

>  * NN options are activated directly after validating them. The rationale is
>    that a peer must accept every valid NN value (RFC 4340, 6.3.2), hence it
>    will either accept the value and send a "Confirm R", or it will send an
>    empty Confirm (which will reset the connection according to FN rules).

This statement is confusing. While the receiving side will activate a
immediately, the sender will now wait for the CONFIRM before activating
the new value. This changed as a result of one of the merged patches. I
would recommend leaving this statement out.

>  * An Ack is scheduled directly after activation to accelerate communicating
>    the update to the peer.
> 
> Signed-off-by: Gerrit Renker <gerrit@xxxxxxxxxxxxxx>
> Acked-by: Ian McDonald <ian.mcdonald@xxxxxxxxxxx>

Signed-off-by: Samuel Jero <sj323707@xxxxxxxx>


Samuel Jero
Internetworking Research Group
Ohio University

Attachment: signature.asc
Description: OpenPGP digital signature


[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