Re: [dhcwg] max-unacked-bndupd

[Damien Neil <Damien.Neil at nominum.com>]

On Aug 17, 2006, at 6:34 AM, Kim Kinnear wrote:
> At 04:53 AM 8/17/2006, Damien Neil wrote:
> > 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.

Thanks for the clarification.


>         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.

Okay, that makes sense.

Looking at this option more closely, I'm wondering about this phrasing:

   The maximum number of BNDUPD message that this server is prepared to
   accept over the TCP connection without causing the TCP connection to
   block.

It seems to me that the focus on TCP connection blocking is  
unimportant.  If the purpose of the max-unacked-bndupd option is to  
ensure that CONTACT messages are transmitted and processed in a  
timely fashion (as stated in section 8.3), then what is important is  
the receiving peer's ability to read BNDUPD messages and queue them  
for processing.

For example, a failover peer that sets its TCP receive buffer size to  
1MB will be able to queue 512 2048-byte BNDUPD messages without  
blocking the connection--but if it reads only one message every  
second, it will take almost ten minutes for it to receive a CONTACT  
message when the buffer is full.

I'm not certain what a better way to phrase the definition of max- 
unacked-bndupd would be, but I don't think it should be described in  
terms of TCP connection blocking.


I'm also curious as to the reason for the focus on ensuring that  
CONTACT messages are processed in a timely fashion.  In the case  
where the failover connection is clogged with BNDUPD messages,  
there's no need to send CONTACTs--since the tSend timer will be reset  
every time a BNDUPD message is sent, and the tReceive timer will be  
reset every time a BNDUPD message is read.  CONTACT messages are only  
useful in circumstances when there is no traffic passing between the  
peers.

                        - Damien



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