[AFS3-std] RX_PACKET_TYPE_PARAMS

[Derrick Brashear]

On Thu, Feb 25, 2010 at 11:34 AM, Tom Keiser <tkeiser@sinenomine.net> wrote=
:
> On Tue, Feb 23, 2010 at 2:21 AM, Derrick Brashear <shadow@gmail.com> wrot=
e:
>> 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. =A0I have a few questions regarding interop. =A0Given
> 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?

Yes. Well, upgrading if we choose to after receiving a reply.

> Detecting peer version upgrades with this
> scheme seems relatively easy: just resend the params packet
> occasionally. =A0However, I'm not entirely sure how to deal with peer
> version downgrades. =A0Do you have any ideas? =A0Are 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?

Reduced performance (in cases where packets must be sliced into
several buffers), downgrade-by-protocol-negotiation for fields where
older limits applied, or aborts. We could codify that those
requirements for a downgrade (that it be handled within protocol,
still work if more slowly, or abort the connection) and I think it
would be reasonable.

--=20
Derrick