Re: [tcpm] Is this a problem?

[MURALI BASHYAM <[e-mail]>]

----- Original Message ----
From: Mark Allman <[e-mail]>
To: MURALI BASHYAM <[e-mail]>
Cc: John Heffner <[e-mail]>; Mahesh Jethanandani <[e-mail]>; [e-mail]
Sent: Monday, November 19, 2007 12:49:19 PM
Subject: Re: [tcpm] Is this a problem? 



> The problem directly stems from TCP's choice to persist
> indefinitely. It seems a very simple notion of allowing the
> application to be the master here (borrowing Joe's words :-)), and
> providing a ceiling on how long this behaviour will continue. This is
> fully in spirit with how the other TCP timers have evolved and added
> over the years. Now this alone does not address the requirements of a
> co-ordinated distributed DOS attack, but the point here is how long
> the connection should be allowed to (re)try sending data is purely an
> *application* decision i.e it MUST be under application control. It's
> a bad design to have an indefinite retry like this in the transport
> layer without providing an override to the app.  

I don't follow this line of thinking.  Let's see ...

  + I don't know where we have added standard timers to TCP except
 where
    we have to (e.g., for time-wait or something).  We basically add
    timers when the only things we can count on is the passage of time.

  + It doesn't seem to me a problem that a connection does this persist
    business indefinitely because both ends are consenting.  It isn't
    like one end is silent or going away.

  + The application *is* in control.  The application can close a
    connection whenever it wants to close a connection.  Giving it a
 way
    to tell TCP when to kill a connection is a distinction without a
    difference. 

Merely closing a connection does not accomplish things, the FIN will simply get
queued behind existing data. What's required is an abort here for termination. But 
abort is a drastic action for the application which it cannot issue w/o some sort of explicit
feedback from TCP...

I don't think you answered my question in any way.  Why do we have to
standardize this?  It seems to me that if some server wants to
 implement
a policy that says "a connection can stay in zero window persist for 60
seconds" then great.  Fine.  I don't care.  Might work fine for the use
case of that server.  Might cause problems for its connections.  But,
 if
that is its policy then wonderful.  Who am I to say that is right or
wrong?  Change the policy and all that still applies.  Seems perfectly
consistent with lots of other things ....

When and how does the application know that the connection entered and exited
the persist condition? Where is the required feedback here? I am not aware of any...
It seems like we are exporting a TCP specific state and knowledge all the way into the 
application to accomplish what seems a simple matter of starting a timer on entry into
persist condition, stop on exit, abort on timeout (if specified by application). 

  E.g., who am I to say which SYNs a TCP should accept?  If they are
  from "bad" IPs and I want to drop them on the floor who are you to
  tell me I am wrong?

  E.g., who am I to say how many retransmits you should conduct before
  determining the peer is somehow gone and you give up?

Why does this persist stuff need to be done in a standard fashion?

Because zero window is a transport layer notion, and it is the responsibility of the transport
layer to provide a robust and fair solution to this issue which benefits ALL applications instantaneously, 
at least that's the way i view it. Why does congestion control require standardization, when every 
client/server application out there is perfectly capable of doing it?  To achieve consistent behaviour
across the widest range of applications...

allman








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


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