Re: [dhcwg] max-unacked-bndupd

[Kim Kinnear <kkinnear at cisco.com>]

At 04:53 AM 8/17/2006, Damien Neil wrote:
>draft-ietf-dhc-failover-12.txt defines a "max-unacked-bndupd" option,  
>which is sent in all failover CONNECT and CONNECTACK messages.  This  
>is defined as follows in section 12.14:
>
>   The maximum number of BNDUPD message that this server is prepared to
>   accept over the TCP connection without causing the TCP connection to
>   block.
>
>I'm attempting to ascertain whether max-unacked-bndupd applies to the  
>number of BNDUPD messages, or the number of binding update  
>transactions.  On the face of it, the above definition would appear  
>to state the former.  However, sections 7.1 and 7.2 include the  
>following phrase:
>
>   The rest of this section is written as though every BNDUPD message
>   contains only a single binding update transaction in order to reduce
>   the complexity of the discussion.
>
>This introduces a certain confusion between BNDUPD messages and  
>binding update transactions.
>
>Since max-unacked-bndupd is defined in section 12.14, which does not  
>include the caveat from sections 7.1 and 7.2, I think that a literal  
>reading of the draft will conclude that this option applies to  
>messages and not transactions. 

        Yes, this was the intent when it was written.

> On the other hand, I think that this  
>option is more useful if it is considered to apply to transactions  
>rather than messages--the size of a message is variable, depending on  
>the number of transactions contained within it, while the size of a  
>transaction is somewhat consistent. 

        Yes ... but ... if you have a pool of buffers, they need to
        be able to handle the maximum message that you expect.  And
        the maximum message size is 2048 bytes, so what you are saying
        with this is how many 2048 byte message you are prepared to
        accept.

        So, it really is about messages and not individual IP address
        transactions in a bulked message.


> (I suspect that the definition  
>of this option may predate the ability to pack multiple transactions  
>in a single BNDUPD, but my knowledge of the history of the DHCP  
>failover draft is insufficient to be certain.)

        Actually, it doesn't, but I can understand how
        you might think so.

        Cheers -- Kim


>Any thoughts on how to treat this option would be appreciated.
>
>                    - Damien
>
>
>_______________________________________________
>dhcwg mailing list
>dhcwg at ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg