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

[Joe Touch <[e-mail]>]

Lloyd Wood wrote:
> At Monday 26/11/2007 08:58 -0800, Joe Touch wrote:
> 
>> I see an OS that has to decide how to allocate resources:
>>
>>        a- leave them with existing apps and prohibit new ones
>>
>>        b- terminate existing apps to make room for new ones
>>
>> I expect that a reasonable, modern OS would do (a).
> 
> That presumes that all TCP connections are long-lived. It permits a
> few long-lived connections to tie up resources that could service
> short-lived connections.
> 
> (http, beep, xml-rpc and other short-lived transactions over TCP
> weren't invented when RFC1122 was written.) 

It presumes only that a connection shouldn't be terminated to make room
for new ones. It says nothing about the duration of the connection.

1122 says that connections that are active - i.e., actively exchanging
packets - MUST NOT be terminated. Connections are terminated only when
applications indicate, OR when the endpoints cannot communicate.

If you start "robbing Peter to pay Paul" - i.e., killing some
connections to make room for others - you end up with a very unreliable
kind of TCP. One where connections just disappear.

Modern OS's don't kill apps to make room for new ones (presuming they're
static in resource use). This is the connection equivalant.

I agree that having the OS - who is SOLELY in view of shared resources -
informing the application when resources are critical, and applications
being designed to decide which connections to keep and which to drop
based on *knowlege about the connections they alone possess*.

However, once a connection is opened, I don't agree that it's the OS's
perogative to kill it for any reason, any more than it would kill a
process that isn't running away. Holding resources already granted is
how current app/OS interfaces work; revocation isn't normal.

Yes, this means that *applications* can be DOS attacked, and they need
to be written to react accordingly.

Joe

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