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: MURALI BASHYAM <[e-mail]>
> Cc: Mark Allman <[e-mail]>; Joe Touch <[e-mail]>; TCP Maintenance and Minor Extensions WG <[e-mail]>
> Sent: Wednesday, November 28, 2007 8:40:12 AM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
> 
> 
> On Nov 27, 2007, at 5:51 PM, MURALI BASHYAM wrote:
> 
> >> Now, it might be that connections that have been in persist
> state
> 
 for
> >> a long period of time are good candidates for the OS to abort
> to
> 
 free
> >> up resources.  But doing that has to be a decision of the OS or the
> >> application, not of TCP.  TCP can keep track of how long connections
> >> are in persist state, so that if the OS or application asks, it can
> >> judiciously choose which ones are the best to abort.
> >
> > Since you going down this path, what's wrong with TCP doing it by  
> > itself having
> > received go-ahead from the application and/or the administrator of  
> > the system?
> > Seems as if we are going to extreme lengths and playing with system  
> > boundary
> > definitions here to avoid making a change where it hurts most (TCP).
> 
> Ok.
> 
> Don't confuse the protocol design with the implementation.  To  
> paraphrase David Clark from many years ago: Strict protocol layering  
> is a great way to design a protocol, but a terrible way to implement  
> it.  In the RFCs, we are dealing with the protocol design, not the  
> implementation, so we need crisp boundaries, and clarity on which
> side
> 
  
> of the boundary things are on.  The implementation is free to do as  
> much blurring between the boundaries as it wants, as long as what
> goes
> 
  
> on the wire is still correct.
> 
> RFC 793 and 1122 talk about how to process a *single* TCP stream.   
> They do not discuss interaction between TCP multiple streams (because  
> from a protocol design standpoint, there shouldn't be any).  When we  
> get into the area of resource starvation, we are now talking about
> how
> 
  
> multiple TCP streams interact between each other through the use of  
> common resources.  Dealing with that is not part of the design of TCP.
> 
> If the user timeout on the SEND call is not sufficient for the  
> application when dealing with a connection, then we would need a  
> proposal to add a new timer to TCP, with a clear description of how  
> the application sets the timer, when TCP should clear/restart the  
> timer, and what to do when the timer goes off.  That has nothing to
> do
> 
  
> resource starvation.  If the timeout on the SEND call would be  
> sufficient for the application, but the TCP implementation does not  
> provide the ability to set a timer on the SEND call, then that is an  
> implementation issue.

I am viewing it this way too, there are 2 aspects here, First aspect : the resource starvation 
mechanism is a TCP implementation notion, i agree. I've agreed to that point of view
in an earlier email. The DOS issue discussed here, and the solution presented (by no means
the only one, others definitely exist) make for an informational nature of draft. There does not
need to be standard ways of handling this.

The second aspect is the ability of the application to explicitly cause the TCP connection
to leave the ZWP state at the specified time independent of available resources. There are 
applications where having this level of control over the TCP connection makes sense (web, game servers). 
But aborting this connection with trigger from TCP or OS or application is a protocol violation, i don't buy the fact 
that if the OS does it, it's not a violation, that's what i was referring to as pure wordplay.

A protocol is a contract between the sender and receiver here, and the contract defines the wire
behaviour. I care about the wire behaviour of the
connection, and if i observe the behaviour of the connection in the ZWP state prior to this change, i see
ACKs and probes exchanged infinitely. With this change (no matter who does it, OS, app, TCP), i see
ACKs and probes being exchanged for some time, followed by a RST segment to abort the connection.

Do you agree that if we do the latter without changing the wording of RFC1122, it's a protocol
violation? My claim all along has been that it is.

If we agree that it's a violation, then it's a standards track nature of draft.

Murali
> 
> If you want to have a higher-level view that goes through and aborts  
> connections in persist state when resources are low, perhaps based on  
> how long they've been in persist state, that is not part of the TCP  
> design.  It might be *implemented* right in the middle of the TCP  
> code, but it is not part of the TCP protocol design.
> 
>             -David Borman
> 
> 




      ____________________________________________________________________________________
Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  http://overview.mail.yahoo.com/


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