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

From: MURALI BASHYAM <[email-masked]>
Date: Sun, 2 Dec 2007 09:56:12 -0800 (PST)

----- Original Message ----
> From: Joe Touch <[email-masked]>
> To: MURALI BASHYAM <[email-masked]>
> Cc: David Borman <[email-masked]>; Anantha Ramaiah <[email-masked]>; TCP Maintenance and Minor Extensions WG <[email-masked]>
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sun, 02 Dec 2007 10:32:52 -0800

MURALI BASHYAM wrote:
...
>> 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.
> 

By your metrics, so are any modifications of the TCP API that require
rewriting the app. Web servers have been multithreaded for a long time -
and even reuse threads to avoid thread creation (see Apache).

> after it has closed the connection AND it does not care about reliable delivery of data to the peer?

If it doesn't care about reliable delivery, why did it use TCP? Why
didn't it ABORT the connection instead of CLOSE?

Your example is inconsistent; if you care about reliable delivery AND
you care about resource attacks you stick around. If you don't, you are
susceptible to DOS attacks.

> that *****TCP**** does not run out of connection and buffer resources, however.

TCP doesn't have resources. The OS does.

> a while back, and i don't think there is any disagreement abt it.

There have been a few of us who believe that the resources under attack
are the OS's, not TCP, and then there are the authors - who believe
otherwise.

> If application resources are under attack, that's application responsibility, of course.

An app IS under attack when its connections are attacked.

Joe