Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]

[MURALI BASHYAM <[e-mail]>]

----- Original Message ----
> From: David Borman <[e-mail]>
> To: Anantha Ramaiah <[e-mail]>
> Cc: TCP Maintenance and Minor Extensions WG <[e-mail]>
> Sent: Friday, November 30, 2007 9:49:04 AM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
> 
> Anantha,
> 
> You're still hung up on the differentiation between the protocol  
> design and the implementation.  You have to make a choice.  Something  
> is either specified within the TCP protocol, and hence is on the  
> standards track, or it is outside the scope of the TCP protocol and  
> would only be an informational RFC; there may be things in both
> areas.
> 
  
> But if you can't cleanly separate the protocol design from the  
> implementation, then you will not be able to make progress in either  
> area.
> 
> The issue is not about where the functionality is implemented, but
> how
> 
  
> it is documented and whether or not it changes the design of the TCP  
> protocol.  My guess is that the best you can hope for in modifying
> TCP
> 
  
> is to add a User/TCP interface that allows the application to set a  
> new timer to abort the connection if it remains too long in persist  
> state (and you'll probably still have resistance).  The interface has  
> to be clearly defined, as well as the semantics on when the timer
> gets
> 
  
> started, restarted and disabled, and what happens when the timer goes  
> off.  Think of it this way: what would you add to RFC 793?  A
> separate
> 
  
> description would describe how an application/OS might make use of  
> this, but that would be informational only.

I think we have enough clarity to do this. The protocol events that start, 
and stop the timer are very well-defined. 

Timer is started when the receiver advertises
a zero window and we enter a state where we are going to be probing the receiver.

Timer is stopped when the receiver advertises a non-zero window that actually allows
the sender to  send data out. Note the distinction that requires the sender to actually
stop the timer when it is allowed by the receiver  to  send data out, preventing tiny window 
(smaller than MSS) advertisements from prematurely  stopping the timer (should not happen
if the receiver silly window avoidance is in effect). Possibly, there is some merit in 
restarting the timer when the receiver offers a tiny window, allowing the receiver some grace
period.

Upon timer expiry, we terminate the connection. If TCP terminates the connection, it works
under all circumstances. The issue here is that TCP cannot inform the application and have the 
application initiate the abort, because it is  not necessary that the application has that connection state 
around anymore, it could have been destroyed already, i've alluded to  this issue before. 

> 
>             -David Borman
> 
> On Nov 29, 2007, at 9:21 PM, Anantha Ramaiah (ananth) wrote:
> 
> > Hi David,
> >
> > Firstly, I appreciate your explanations on TCP design and the
> > differences between standard and implementation, those are all good.
> >
> > That said, it appears that this is what is being said (at least
> that
> 
  
> > is
> > what is being inferred in the email exchanges) :-
> >
> > Case 1:
> > Abort by the application and OS
> > ==================================
> >
> > "The application OR any entity (like OS) which is instructed by the
> > application to abort the TCP connection when deemed necessary".
> "The
> 
  
> > OS
> > can abort the TCP connection when deemed necessary". These actions  
> > seems
> > to enjoy full compliance of RFC 793/1122.
> >
> > Also an example : if there are 270 connections hanging out in persist
> > state for 110 days, the system administrator chooses to clear some of
> > these connections, now system administrator is acting on behalf
> of
> 
 the
> > system and may not be the application, this is not a violation of the
> > RFC, it appears.
> >
> > WHEREAS
> >
> > Case 2:
> > Aborts done inside TCP layer
> > ============================
> >
> > Assuming that one implementation chooses to have a design like :
> > instructs each individual components in the system like transports  
> > layer
> > to abort some connections and thereby relinquish system
> resources
> 
 when
> > deemed necessary using an explicit or implicit feedback from the
> OS.
> 
  
> > Now
> > this action seems to be violating the RFC since it was done
> inside
> 
 the
> > jurisdiction of TCP code. I am having hard time understanding
> this.
> 
 To
> > me, it is pure implementation thingy.
> >
> > To me all the above actions (case 1 and 2), either are all
> compliant
> 
  
> > to
> > RFC OR all of them aren't. May be it is just me.
> ...
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tcpm
> 




      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm