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

----- Original Message ----
> From: Joe Touch <touch@ISI.EDU>
> To: MURALI BASHYAM <murali_bashyam@yahoo.com>
> Cc: David Borman <david.borman@windriver.com>; Anantha Ramaiah <ananth@cisco.com>; TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
> Sent: Sunday, December 2, 2007 9:04:41 AM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
> 
> 
> 
> MURALI BASHYAM wrote:
> ...
> >>
> >> MURALI BASHYAM wrote:
> >> ...
> >>> 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.
> >> 
> >> And I have already shown how to address it - SO_LINGER.
> >> 
> >> In the case of a Unix close() call, this can be used to cause 
> >> close() to block until either the graceful shutdown completes
> >> (i.e., all data is sent and ack'd, and the other end closes) OR a
> >> timer expires.
> >>
> >> SO_LINGER already supports a timer for this purpose.
> >>
> >> Can we please stop trying to add to TCP that which
> ***ALREADY***
> 
 exists
> >> in the implementation?
> > 
> > Turning SO_LINGER on causes the application to pay a penalty in
> the
> 
 normal
> > scenario, where the close call will block even with a
> legitimate
> 
 receiver (or a slow
> > network). This is precisely why applications do not use it, it
> ties
> 
 up resources 
> > unnecessarily, and how about applications that want
> non-blocking
> 
 semantics?. High
> > performance applications care about non-blocking semantics.
> 
> Modern applications programmers are aware of multithreading.
> 
> You can either leave the app around watching the connection, or offload
> that to a socket library - i.e., a SOCKET timer (note - note a protocol
> timer).
> 
> > Let's stop recommending to applications how to use the 
> > socket layer, we have to approach this in a manner that
> doesn't
> 
 question or change
> > their socket layer usage model.
> 
> But you want to change their protocol interface model instead?
> 
> > Application changes should be incremental and not
> > disruptive, that's the idea of doing this in the transport layer
> in
> 
 the first place.
> 
> Applications should have changed long ago. Some definitely need
> to
> 
 catch
> up. There is no way to handle DOS attacks with legacy applications
> written in a legacy manner.

I think you missed my point, let me explain. Application here does NOT care
about reliable delivery of data to the peer after it has closed the connection.
Hence SO_LINGER is out. Web behaves this way and by any standards it is not a legacy
application.  

Can you explain why an application should keep a connection or socket state around 
after it has closed the connection AND it does not care about reliable delivery of data to the peer?
If it did, they would be using SO_LINGER already, hence my comment about not making
socket layer usage recommendations to the app. Even in this scenario, it's important
that *****TCP**** does not run out of connection and buffer resources, however.

I think the key point this issue illustrates is that it is TCP's resources which are under attack
here, and not the application's. I think this distinction has emerged in this email thread 
a while back, and i don't think there is any disagreement abt it.

In most modern systems, these are managed as distinct resources and TCP resources (read
connection memory and buffer memory) can get starved with app resources available in plenty.
If application resources are under attack, that's application responsibility, of course.

Murali

> 
> Joe
> 
> 

      ____________________________________________________________________________________
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
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm