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

From: MURALI BASHYAM <[email-masked]>
Date: Wed, 28 Nov 2007 17:32:07 -0800 (PST)

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

---

From: David Borman <[email-masked]>
Date: Thu, 29 Nov 2007 11:09:29 -0600

On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote:
...
> 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

Fine.  Call it wordplay.  There's nothing wrong with that, because you  
*have* to get the words right.  You have to be crisp on the protocol  
definition.  The implementation can blur the boundaries, but the  
protocol definition can't.   The aborting of a connection (whether in  
persist or any other state) when the other side is alive and  
responding has to be done by the application.  TCP should not be doing  
that without direct instructions from the application.  Whether that  
is done directly by the application by using the existing abort or  
user timeout interface, or whether a new interface is defined to allow  
the application tells the OS to run a timer and abort the connection  
when the timer goes off, it is still being done under the direction of  
the application.

> behaviour.

The TCP protocol is what is defined in RFC 793/1122, and any other  
RFCs that are applicable.  It is more than just the wire behavior.

> I care about the wire behaviour of the

There already exists two mechanisms for the application to abort a  
connection, directly with the abort interface, or indirectly with the  
user timeout on the send interface, and you will get the same wire  
behavior, a connection in persist state gets aborted.

The only protocol problem here is to have TCP abort a connection in  
ZWP state without the application having first explicitly asked for  
that to happen.  And if you need a new interface to provide that  
functionality, then that will be a change to the TCP protocol.

The OS freeing up resources when they run out by doing things like  
aborting connections is not a protocol violation, because it isn't TCP  
making that decision.  Take that to the extreme, and you'd be arguing  
that the system crashing is a TCP protocol violation, and that's just  
silly.

> If we agree that it's a violation, then it's a standards track  

If it changes TCP, in this case adding a new User/TCP interface, then  
it should be on the standards track.

			-David Borman

---

From: Ted Faber <[email-masked]>
Date: Thu, 29 Nov 2007 09:27:42 -0800

Speaking only for myself.

On Wed, Nov 28, 2007 at 05:32:07PM -0800, MURALI BASHYAM wrote:
> 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 you believe that aborting a connection advertising a zero window is a
violation of the TCP specs, there's a lot of violation going on.  Any
time a process is killed or a machine goes down, TCP connections are
aborted (some advertising a zero window).  I find it hard to consider
all of those as non-conforming TCPs.

Now, looking at the text in front of us (RFC1122 in particular), one can
either believe that the TCP designers really intended for zero-window
connections to be maintained by any means possible, including starving
the host of memory and processing power, or that they intended what
David Borman described - to lay out the behavior of the protocol in the
absence of resource contention.  I prefer the latter; I'm sure the
designers considered the possibility of resource exhaustion and David's
interpretation allows plenty of room for operating systems and
applications to address it through calling ABORT on well-chosen
connections.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Nov 2007 10:04:00 -0800

FWIW, I agree with David's position here, and appreciate his raising the
distinction between implementation and specification.

Whether the app or the OS decides to terminate via the existing TCP API
ABORT call, that's an implementation issue.

I'd have opinions as to which is more correctly *implemented*, but
that's an implementation issue, not a protocol issue.

When resources are starved, I think good implementations inform the app
and let the app decide what to do. I don't think they have the OS run
down things it *thinks* aren't useful and free them. Again, however,
that's an implementation issue. I'll argue it, but it's not relevant to
the key question of whether we need a new protocol mechanism.

One final point:

...
>> contract defines the wire
>> behaviour.
> 
> The TCP protocol is what is defined in RFC 793/1122, and any other RFCs
> that are applicable.  It is more than just the wire behavior.

This is as I have stated on multiple lists.

If there is a strong need for an RFC to explain concepts that are
ambiguous, this is MUCH more important than any other raised in this
entire thread.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 29 Nov 2007 19:21:07 -0800

Hi David,

Firstly, I appreciate your explanations on TCP design and the
differences between standard and implementation, those are all good. 

That said, it appears that this is what is being said (at least that is
what is being inferred in the email exchanges) :-

Case 1:
Abort by the application and OS
==================================

 "The application OR any entity (like OS) which is instructed by the
application to abort the TCP connection when deemed necessary". "The OS
can abort the TCP connection when deemed necessary". These actions seems
to enjoy full compliance of RFC 793/1122. 

Also an example : if there are 270 connections hanging out in persist
state for 110 days, the system administrator chooses to clear some of
these connections, now system administrator is acting on behalf of the
system and may not be the application, this is not a violation of the
RFC, it appears.

WHEREAS

Case 2:
Aborts done inside TCP layer
============================

Assuming that one implementation chooses to have a design like :
instructs each individual components in the system like transports layer
to abort some connections and thereby relinquish system resources when
deemed necessary using an explicit or implicit feedback from the OS. Now
this action seems to be violating the RFC since it was done inside the
jurisdiction of TCP code. I am having hard time understanding this. To
me, it is pure implementation thingy.

To me all the above actions (case 1 and 2), either are all compliant to
RFC OR all of them aren't. May be it is just me.

Please read on...

Lets take the example of one mitigation for "SYN attacks" (I think also
mentioned in the recent SYN flood informational RFC)

It talks about detecting "possibly" malicious connections hanging out
there in half-ESTAB state and the possible mitigations. One of the
simple mitigations is to toss the "oldest" embryos and make room for the
"new ones" and all of these actions doesn't violate any RFC. 

It could be argued for SYN flood case : Why should one do that, they can
let the connections hang out forever, timeout happens OR the host
crashes etc., the point is that you want to make an "attempt" to permit
new, possibly legitimate connections, conserve system resources for
legitimate clients. Is this foolproof?, no, there are corner cases
everywhere in every solution. That doesn't mean you shouldn't be having
anti-DOS solutions in place.

Now the above draft talks about connections which are going to be
established and NOT already established. But I can see a lot of
similarities in the goals between the SYN flood and persist drafts. 

Now, I know people may say that the persist draft is totally different
since you are talking about connection that are in >= ESTAB state. The
state of affairs so far seems to be : you can't simply touch the TCP
connection persisting since RFC 1122 tells you to keep this forever, but
wait, you can kill them, but please do so only in the context of the
application and may be OS, but not inside TCP since doing so violates
RFC. But remember, it could be that someone chose to enhance the their
TCP stack's anti-DOS capabilities with some algorithm they believed
would help, terming that as a RFC violation seems too far fetched.

Anyways, I am stuck on the way RFC compliance is measured here and I am
thinking we are applying too much layering here than mandated by the
generic nature of the existing RFC.

$0.02,
-Anantha

> -----Original Message-----
> From: David Borman [mailto:[email-masked]] 
> Sent: Thursday, November 29, 2007 9:09 AM
> To: MURALI BASHYAM
> Cc: TCP Maintenance and Minor Extensions WG; Mark Allman; Joe Touch
> Subject: Re: Summary of responses so far and proposal moving 
> forward[WasRe:[tcpm] Is this a problem?]
> 
> 
> > game servers).
> that if the 
> > OS does it, it's not a violation, that's what i was referring to as 
> > pure wordplay.
> 
> *have* to get the words right.  You have to be crisp on the 
> protocol definition.  The implementation can blur the 
> boundaries, but the  
> responding has to be done by the application.  TCP should not 
> be doing that without direct instructions from the 
> application.  Whether that is done directly by the 
> application by using the existing abort or user timeout 
> interface, or whether a new interface is defined to allow the 
> application tells the OS to run a timer and abort the 
> connection when the timer goes off, it is still being done 
> under the direction of the application.
> 
> 
> > contract defines the wire behaviour.
> 
> The TCP protocol is what is defined in RFC 793/1122, and any 
> other RFCs that are applicable.  It is more than just the 
> wire behavior.
> 
> 
> > 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.
> >
> > RFC1122, it's a protocol violation?
> > My claim all along has been that it is.
> 
> There already exists two mechanisms for the application to 
> abort a connection, directly with the abort interface, or 
> indirectly with the user timeout on the send interface, and 
> you will get the same wire behavior, a connection in persist 
> state gets aborted.
> 
> The only protocol problem here is to have TCP abort a 
> connection in ZWP state without the application having first 
> explicitly asked for that to happen.  And if you need a new 
> interface to provide that functionality, then that will be a 
> change to the TCP protocol.
> 
> The OS freeing up resources when they run out by doing things 
> like aborting connections is not a protocol violation, 
> because it isn't TCP making that decision.  Take that to the 
> extreme, and you'd be arguing that the system crashing is a 
> TCP protocol violation, and that's just silly.
> 
> >
> >
> > If we agree that it's a violation, then it's a standards 
> track nature 
> > of draft.
> 
> If it changes TCP, in this case adding a new User/TCP 
> interface, then it should be on the standards track.
> 
> 			-David Borman
> 
> 
>

---

From: David Borman <[email-masked]>
Date: Fri, 30 Nov 2007 11:49:04 -0600

Anantha,

You're still hung up on the differentiation between the protocol  
design and the implementation.  You have to make a choice.  Something  
is either specified within the TCP protocol, and hence is on the  
standards track, or it is outside the scope of the TCP protocol and  
would only be an informational RFC; there may be things in both areas.  
But if you can't cleanly separate the protocol design from the  
implementation, then you will not be able to make progress in either  
area.

The issue is not about where the functionality is implemented, but how  
it is documented and whether or not it changes the design of the TCP  
protocol.  My guess is that the best you can hope for in modifying TCP  
is to add a User/TCP interface that allows the application to set a  
new timer to abort the connection if it remains too long in persist  
state (and you'll probably still have resistance).  The interface has  
to be clearly defined, as well as the semantics on when the timer gets  
started, restarted and disabled, and what happens when the timer goes  
off.  Think of it this way: what would you add to RFC 793?  A separate  
description would describe how an application/OS might make use of  
this, but that would be informational only.

			-David Borman

...

---

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 30 Nov 2007 13:40:11 -0500

> From: Anantha Ramaiah (ananth) [mailto:[email-masked]]
> Sent: Thursday, November 29, 2007 7:21 PM
> To: David Borman
> Cc: TCP Maintenance and Minor Extensions WG
> Subject: RE: Summary of responses so far and proposal
> movingforward[WasRe:[tcpm] Is this a problem?]
> 
> Hi David,
> 

System administrators can kill an application. Allowing them to kill
just
some of the application's connections only helps the application.

There is no point in any RFC telling sys admins/users that they MUST NOT
do
things that they inherently have the capability and right to do.