In message <[EMAIL PROTECTED]>
Erblichs writes:
>  
> Abhay D.S.,
>  
>       Sorry about the top post, but..
>  
>       TCP has a slow-start mechanism with ACK
>        clocking to verify completion of xmit'ed data,
>       until a threshold is met or,

Not a good description of TCP's window mechanism but off topic anyway.

>       Until 2 or 3 DUP ACKs are seen and then
>       rexmited or a coarse grain timeout occurs,

3 Dups.  Its called fast retransmit.

The timer is based on an estimate of RTT unless there is no basis to
determine RTT.

>       However, TCP does not guarantee that the
>       recvr will actually recieve data xmited
>       by the send, just that if the data arrives
>       then, it will send acks..

Are you claiming TCP doesn't guarentee arrival of data?  It does.

>       And again, their is no guarantee that the
>       acks will be recieved, so the sender can
>       send more data.

The sender retransmits in the complete absense of ACKs after 3 seconds
if the initial retransmit is lost.  Then doubles the timer up to 75
seconds (odd default) and keeps that up for 15 minutes (by default,
all this is changeable).

>       Mitchell Erblich

So what's your point?  Acee's response regarding using the MIB is
still valid.  With SNMP you *in theory* have to retransmit but if your
NMS is not braindead and overrunning equipment with SNMP gets then
you'll get the response because it is on IP prec 6 the whole way
(unless your OPs staff is also not too swift).  If you do lose an SNMP
get, a retry or even a series of retries is not the end of the world.

Curtis


btw - There is also FTTCP (fault tolerant) from Avici (patented but I
beleive the patent is invalid) which keeps TCP going even if the
primary server goes down (hacked TCP does application level 2 phase
commit on primary and standby server before sending ACK).  Amber and
others used a secondary that snoops on the TCP data for another form
of fault tolerant TCP adequate for BGP and manangement sessions.  But
this is OSPF WG so we're off topic.


_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf

Reply via email to