Re: [tcpm] New I-D

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

> 
> > 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.
> 
> So, let me step back.  I should have been more
> careful.  I think this is
> a problem with the draft-not the approach.  That is,
> I can certainly
> understand why a TCP would want to not depend on
> apps.  But, the text in
> the i-d doesn't lead me to that conclusion and I
> think it is at very
> best dubious in some places.

If it is dubious, then we can correct it, and perhaps
we need to explain the motivation for that more
clearly.

> 
> > 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.
> 
> We are having a terminology problem here.  I meant
> "OS" as in the thing
> that contains the TCP implementation.  I did not
> mean that an OS could
> blindly reap off resources without understanding
> anything about TCP.

Okay, we are on the same page :-).
> 
> Let me put it this way ... This seems to me to be a
> TCP
> **implementation** issue.  Why should we need to
> standardize this issue
> and not other internal resource contention issues? 
> Why is this anything
> but a very local problem that can be handled by the
> TCP implementation
> in whatever way that implementation chooses?

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?

> 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
the receiver that may not be addressed here, such as
the receiver opening the window a little and then
closing it that fernando mentioned, thus leading to a
longer term issue? We need to build heuristics into
the solution that can detect this and other types of
anomalous receiver behaviour, and take appropriate
action. And the heuristics themselves need to be based
on a notion of a well behaved receiver in this
scenario, to avoid false positives.

Murali

> 
> allman
> 
> 
> 
> 

____________________________________________________________________________________
TV dinner still cooling? 
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/

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