[AFS3-std] RX_PACKET_TYPE_PARAMS

[Tom Keiser]

On Tue, Feb 23, 2010 at 2:21 AM, Derrick Brashear <shadow@gmail.com> wrote:
> Currently, this as well as the 2 types above it are unused and as far
> as I can tell, have been unused since at least afs 3.2.
>
> I'd like to propose the use of this for a peer to share its network
> and packet settings using registered tags and values, notably the
> number of jumbogram fragments a side is prepared to send and receive,
> and the maximum fragment size a side is prepared to receive (the goal
> being large packets)
>
> Before I write up a formal proposal on this I thought I'd float a
> trial balloon. Brief discussion in Edinburgh did not yield any major
> dissent though the proposal lacked any real meat at the time.
>

Hi Derrick,

This is intriguing.  I have a few questions regarding interop.  Given
that this packet type won't get a response from contemporary clients,
is the idea to handle this as an asynchronous negotiation, upgrading
if/when we receive a reply?  Detecting peer version upgrades with this
scheme seems relatively easy: just resend the params packet
occasionally.  However, I'm not entirely sure how to deal with peer
version downgrades.  Do you have any ideas?  Are we simply
anticipating that all uses of this negotiation scheme will lead to the
peer sending an abort if it downgrades to an earlier rx
implementation?

Cheers,

-Tom