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 08:47:30 -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: Friday, November 30, 2007 10:31:50 PM
> Subject: Re: Summary of responses so far and proposal moving forward[WasRe:[tcpm] Is this a problem?]
> 
> 
> 
> 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.

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. Application changes should be incremental and not
disruptive, that's the idea of doing this in the transport layer in the first place.

> Joe

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

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 02 Dec 2007 09:04:41 -0800

MURALI BASHYAM wrote:
...
>>
>> MURALI BASHYAM wrote:
>> ...
>>> The issue here is that TCP cannot inform the application and have the
>>> the application has that connection state around anymore, it
>>> could have been destroyed already, i've alluded to this issue
>>> before.
>> 
>> 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.
>>

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).

> their socket layer usage model.

But you want to change their protocol interface model instead?

> Application changes should be incremental and not

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.

Joe