Subject: RE: [Idr] ADJ RIB IN queries

From: "john smith" <[email-masked]>
Date: Mon, 27 Sep 2004 14:17:24 +0000

Thanks,

while a, may have an advantage of relying on TCP backpressure (depending on 
the underlying TCP stack in use), it  would imply extra memory consumption 
on the receivers side as it would either have to store up the incoming 
messages or make multiple copies of the adj_rib_in if the sender too is 
churning.

I saw the end of RIB marker and the FT state bit  in of the other drafts and 
was wondering if that may have usage in this case. In other words,  one 
would have to ack the receipt for an End of RIB marker/FT state intact 
eitherways for that feature to be implementable.

Changing keepalive timers to get the behaviour seems like another option....

thanks again,

>From: Michael Dell <[email-masked]>
>To: 'john smith' <[email-masked]>, [email-masked]
>Subject: RE: [Idr] ADJ RIB IN queries
>Date: Mon, 27 Sep 2004 14:35:13 +0100
>
>John
>
>I would have said that how a stack deals with receiving an update whilst 
>the
>Adj-RIB-In(ARI) is locked is an implementation issue.  Received updates 
>that
>the stack is not yet able to process as it is already processing an update
>(which is when the ARI would be locked) would probably be buffered by the
>sockets layer, and this can apply back-pressure if your BGP implementation
>is not reading the data fast enough - but that's just 1 approach.
>
>There is no defined method within the BGP protocol to request that a peer
>hold off advertising updates to you.
>
>Adj-RIBs-In would be the plural of Adj-RIB-In.
>
>Regards
>
>Mike Dell
>
>-----Original Message-----
>From: john smith [mailto:[email-masked]]
>Sent: 27 September 2004 11:53
>To: [email-masked]
>Subject: [Idr] ADJ RIB IN queries
>
>
>Hi folks,
>
>Would appreciate if someone could clarify,
>
>Incase the ADJ RIB IN is locked, and an update message arrives, is it
>
>a. stored in a message queue for sequential processing?
>or
>b. allowed to modify the RIB? (does not seem to make sense)
>or
>c. is there a way to notify adjacent peers that the RIB is locked hence
>updates should not be sent till a status change is sent to peers.
>
>In other words, there has to be one more abstraction/queue prior to the
>ADJ_RIB_IN, if my understanding is correct?
>
>And incase it is a, can withdraws and implicit withdraws be applied to the
>queue in a, rather than at the ADJ_RIB_IN if such a situation arises,
>(though the whole queue would be processed at once but just an
>optimization)?
>
>Another clarification I would like to seek,
>is it adj_RIB*s*_IN or adj_RIB_IN?
>
>-thanks
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 27 Sep 2004 12:48:02 -0400

> messages or make multiple copies of the adj_rib_in if the sender too is 

Lets not get silly here.  There is no such thing as a TCP
implementation that does not apply backpressure (ie: doesn't withhold
the ACKs if the reader hasn't emptied the buffer) and it is also a
violation of the protocol to tell the other side that your receive
buffer is bigger than it really is.

So the TCP flow is always bufferred on the receive side in the socket
layer (or whatever it is called in some other implementation) and the
sending side always stops sending due to lack of ACKs.  If not
someone's TCP implementation is broken and needs to be fixed.

> Changing keepalive timers to get the behaviour seems like another option....

If the socket is stalled for 90-180 seconds you've got a real problem
on your hands.  You should be sending keepalives anyway and should not
declare that the session is dead on the basis that you haven't read
from the socket in 90-180 seconds.

All of this is implementation details and not really in scope for
discussion of the protocol on this list.  Plus it has come up numerous
times in the last 10-12 years and has been discussed, sometimes in
great detail, and answered numerous times.

This is not a mailing list for newbie questions.  If you need a review
of basic TCP operation this is not the place for it.

Curtis