Re: [tcpm] New I-D

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

> 
> Regarding:
>  
>
http://www.ietf.org/internet-drafts/draft-mahesh-persist-timeout-00.txt
> 
> Wes:
> > [...] but it looks to me like this is more of an
> OS mechanism to
> > manage resources rather than a protocol-based
> mechanism.  Is this
> > correct? 
> 
> I'm with Wes here.
> 
> I just took a spin through the draft and am left
> with three thoughts ...
> 
>   + You say apps don't have a good role to play even
> after citing apps
>     that 'pause' as the culprit.  I can't make these
> things agree in my
>     head.  Even in the absence of TCP-specific
> information it seems that
>     these apps could time themselves out if no
> progress is being made
>     (i.e. data getting exchanged).

Well behaved applications usually SHOULD do this, i
agree, can't be guaranteed though. Leaving the problem
to be addressed by the app, does not ensure timeliness
from the point of view that TCP resources such as
buffers and connections are scarce and by how much
etc. The scheme lacks robustness if left to the
application, and for it to be beneficial, ALL
applications running on a system should be doing it,
otherwise there is the weakest link.

> 
>     (Further, things like HTTP sends after which the
> app goes away and
>     then getting wedged into persist don't worry me
> much.  That sounds
>     like a once in a blue moon sort of situation to
> me.)
> 
>   + This seems fundamentally like an operating
> system resource issue to
>     me and not something for a networking standards
> body.  OSes deal
>     with all sorts of resource contention issues
> without standards.  Why
>     does this problem need to be solved the same way
> by each OS?

At first glance, it does seem like an OS resource
issue, but TCP connections can have data backlogged in
their send queues for a variety of reasons and for
variable amounts of time, i am not sure how a protocol
unaware OS based solution can make the distinction
between the network causing the backlog transiently,
and a legitimate vs rogue receiver causing the backlog
etc, i feel that making it TCP protocol specific
(something designed only for persist state) allows for
well controlled, granular solution(s) and heuristics
to detect specifically misbehaving receivers in this
scenario.

> 
>   + In particular, I think you have solved the
> problem wrong.  Don't get
>     me wrong ... maybe it is perfectly OK for your
> purposes and it is
>     fine with me if you want to use it.  However, I
> would want something
>     a little smarter to really avoid the mythical
> attacks you describe.
>     All you did was to cap the length of
> connections.  So, conceivably a
>     periodic attack could still keep all your
> resources busy.  It seems
>     to me that you'd want to use some sort of scheme
> that actually took
>     into account contention and resource exhaustion.
>  E.g., some sort of
>     LRU what-has-been-in-persist longest when you
> need new resources and
>     they are not available sort of culling scheme? 
> Or, when you have
>     exhausted X% of your resources to keep some in
> reserve.  That might
>     be wrong and busted itself (it is quickly off
> the top of my head),
>     but it at least takes into account the resource
> contention unlike a
>     naive timeout.
> 

The LRU scheme can be overlaid on top of the timeout
scheme to ensure a flexible and adaptive solution
quite easily, i agree. It still calls for tracking
connections bottlenecked specifically by the infinite
persistence problem.

Murali

> Just my two bits ...
> 
> allman
> 
> 
> 
> > _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm
> 

____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

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