Re: [tcpm] New I-D

--- Mark Allman <mallman@icir.org> wrote:

> 
> > It is an implementation to correct a problem
> caused by
> > the protocol's REQUIREMENT for a sender to be in
> an
> > infinite persistence state, thus allowing for
> abuse by
> > a misbehaving receiver side application (or by a
> lot
> > of well-behaved receivers). The draft is outlining
> a
> > solution to the problem (there could be others).
> The
> > idea in the (informational) draft is to highlight
> to
> > the group that requirement of the protocol, its
> > consequences and a possible solution.
> > 
> > Are you suggesting that any requirements of the
> > protocol specification that lead to a potential
> denial
> > of service type of scenarios and thus causing
> internal
> > resource contention, and/or any other network
> issues
> > are all to be considered 'implementation' ?
> Shouldn't
> > we look at the requirements of the protocol a
> little
> > more carefully?
> 
> Two things:
> 
>   + I think it is a big stretch to say this
> requirement should hold in
>     resource constrained situations.  There are a
> zillion examples where
>     a system is supposed to do something, but if it
> can't do it then it
>     can't do it.  And, if a system cannot handle all
> the established +
>     requested connections then something has to
> give---and, what that is
>     ought to be a policy decision.
> 
>   + If you do want to read the standard as requiring
> a TCP to keep this
>     connection in the face of everything then you
> don't need an
>     informational because you cannot change a
> protocol requirement with
>     an informational.
> 

I am not sure what the status of the draft is supposed
to be, would experimental be a more appropriate
status?
Aside from the status of the draft, the more
fundamental point is whether we agree that this is a
protocol specific requirement leading to a problem for
which there is a protocol specific/aware solution we
can put in place. 

> > > And, then why is the proposed solution the right
> > > one?
> > 
> > It does solve the problem it sets out to based on
> a
> > "total time allowed to be in persist state" type
> of
> > cap on the duration.
> > 
> > Are you implying there could be other behaviours
> from
> 
> I am not implying anything.  In my previous note I
> said that a simple
> timeout is a poor solution to the problem because it
> does not actually
> take into account that resources are constrained.
> 
> Let me try an example...  Let's say we set this
> timer to 10 minutes.  A
> TCP can stay in persist for 10 minutes.  Two
> possibilities:
> 
>   + The 10 minutes goes by and this is the only
> connection on the
>     machine. 
> 
>     Why purge the connection?  The ends are both
> actively still
>     interested and the connection is not causing any
> problems.
> 
>     (Clearly, we could say this is just the
> machine's policy---that
>     connections in persist for 10 minutes get
> purged.  And, that is fine
>     if someone wants to do that.  But, in this case
> the connection is
>     posing no problem and so purging the connection
> is not addressing a
>     problem, just being done due to some sort of
> house keeping policy.)
> 
>   + The 10 minutes goes by and the machine is
> heavily loaded and has
>     turned away dozens or hundreds of connections
> because of this
>     overloaded situation.
> 
>     In this case, purging the connection may offer a
> little relief and
>     let other connections come in.  Maybe these will
> complete and this
>     is good.  Or, maybe this is an attack and so the
> next connection
>     will just wedge us for another 10 minutes.
> 
>     The point here is that any relief we see from
> this purging is by
>     happenstance and not because we did something to
> actually address
>     the resource constraint problem.  Why did we
> wait 10 minutes?  Why
>     not 9?  Or 11?  If we want to deal with resource
> issues then we need
>     to kick something in when resources are limited.
>  Kicking some
>     connections out at some arbitrary point is just
> a *hope* that in
>     some cases it will help.
> 
> What am I missing here?

I thought we agreed that a resource based demand
driven scheme (based on who has been idle for the
longest time) can be used on top of the timeout based
policy scheme. Doesn't that address the issue are
raising here?

Thx,
Murali
> 
> allman
> 
> 
> 
> 

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm