Subject: Forward Progress Reg:

From: Arun Jose <[email-masked]>
Date: Mon, 8 Apr 2002 02:31:48 -0700 (PDT)

Hi all, 
        
        I am pretty new to this working group.
 I have a question regarding  forward progress described in the RFC 2461. 
At what instance of a connection , TCP or anyother connection oriented protocol 
will inform the IP about a forward in progress?. 

RFC 2461 says 

"  When possible, upper-layer protocols provide a positive confirmation that 
a connection is making "forward progress", that is,  previously sent data is 
known to have been delivered correctly 
(e.g.,   new acknowledgments were received recently).  "

 What time should IP expect this hints from the upper layer protocol ?
 Will it be with all the packets sent from the upper layer or 
do we have any mechanism like a setsockopt () so that the upper layer can 
inform the IP about the forward progress? Please help.

Thank You in advance

(Arun Jose)

---------------------------------
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 08 Apr 2002 08:51:41 -0500

Hi Arun,

>  What time should IP expect this hints from the upper layer protocol ?

Upper layer protocols should decide when in it possible for them to give advice
to IP regarding whether another node is reachable.  This advice may be given
when there has been a positive demonstration of forward progress on a connection
(i.e. an acknowledgement of data that was previously sent, a response to a query,
etc.).  It should not be given due to received traffic that may only confirm one way
connectivity between the remote node and the local node (i.e. receiving a query,
receiving new data, etc.).

For TCP, the advice may be given when an acknowledgement is received for 
data that has not been previously acknowledged.  

UDP would not offer this advice at all, as it never knows that two way connectivity
is available.  However, higher layer UDP applications may give advice when they
receive confirmation of two way connectivity.

In many cases, the IP layer may not receive this type of advice about a 
communication.  For instance, an SNMP agent may never receive a positive
indication that its NMS is reachable.  This applies to any responder in a query/
response system.

I don't know to what extent this optimization has been implemented in current
stacks -- Does anyone know if KAME implements this?

I also don't know what API support, if any, is provided to allow UDP applications
to provide this type of advice to IP.  Anyone?

Margaret

>Yahoo! Tax Center - online filing with TurboTax 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 12 Apr 2002 11:09:50 +0900

>>>>> On Mon, 08 Apr 2002 08:51:41 -0500, 
>>>>> Margaret Wasserman <[email-masked]> said:

> stacks -- Does anyone know if KAME implements this?

Yes, we (KAME) implemented it in the TCP layer, though I don't know
how much the code optimizes the situation.  Also, our implementation
only works when the TCP peer is a neighbor, that is, it does not
provide the reachability confirmation about the first hop router for
an off-link peer.

> to provide this type of advice to IP.  Anyone?

Some older versions of rfc2292bis (the advanced API) spec had a socket
option (mainly) for UDP sockets to tell the kernel the reachability of
a neighbor, and we implemented the socket option in KAME 2 years ago.
However, during the working group last call for the draft we decided
to remove the option from the spec, since we've never found examples
*in the real world* where the option is really useful - in fact,
there has been no application that uses the socket option for 2 years.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------