Thanks Chuck for the additional clarification. That helped me to understand better.
Sorry that I missed it in my reading.
Yes the suggested changes look great.
Cheers
Suhas
On Wed, Jan 29, 2020 at 7:23 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> On Jan 29, 2020, at 12:03 AM, Suhas Nandakumar <suhasietf@xxxxxxxxx> wrote:
>
> Thanks Chuck for the response. Please see inline
>
>> On Tue, Jan 28, 2020 at 7:52 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>>
>> Zero is a permitted value for the size fields. Section 5.2 explains how
>> to compute the actual buffer size. If those fields contain zero, the
>> actual send and receive buffer sizes would be 1024 octets.
>
>
> [Suhas] I am not sure if i am reading it right here. Section 5.2 would result in the
> value of -1 if the min of the values is Zero (0/1024 - 1). Isn't it so ?
Section 5.2 says:
Inline threshold sizes from 1KB to 256KB can be represented in the
Send Size and Receive Size fields. A sender computes the encoded
value by dividing the actual value by 1024 and subtracting one from
the result. A receiver decodes this value by performing a
complementary set of operations.
Here, "actual value" means the real size of the buffer. A 1024-octet
buffer would result in (1024 / 1024) - 1 = 0.
The computation done by the receiver is the inverse:
(0 + 1) * 1024 = 1024
I could replace "actual value" by "buffer size, in octets". Would it
help if the text also spelled out the inverse computation?
--
Chuck Lever
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
