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

I managed to read all the responses so far on this thread. At the time
of writing this email, there have been 54 email exchanges (includes the
authors' responses) around 9 people have responded so far not counting
the private email exchanges. In order to prevent rat-holing this further
I would like to step back a little and pose the following questions :-

A) Do we agree that it is a problem ? [the title of the thread]

   Most people seem to agree on this.

B) Do we think this is an issue to be dealt at the transport layer?

   Here there seems to be mixed reaction. Granted that there may be many
people feeling that this is an application issue and not a transport
issue.

Now expanding on B), 

Now the draft is talking about 2 things actually 3 things.

1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC
1122 tells the connections MUST persist forever as long as ACK's are
received. Now, clearly as demonstrated in the draft, there needs to be
some ammount of robustness that can be built into the TCP layer, which
can allow the connection to be aborted after some stipulated time. Is
this considered a change in the standards? 

2) The draft also outlines a solution that can be helpful to deal when a
particular host is compromised with malicious intent. Agreed this may
not be the only solution possible, but it is one such. This purely falls
into "INFORMATIONAL" category. There is no TCP protocol change, it is
upto the implementation to chose an algorithm of choice. I think the
majority of the objection so far seems to be w.r.t point : "why TCP
layer should be responsible for resource allocation shemes"?  Again, I
think this is merely a suggestion and some implementations can chose to
implement it that way, there is no need to standardize this.

3) It also DOES mention about the application's role. Ie., in particular
it suggests the following :- 
   "Applications can assist TCP's role in solving this problem.  They
can
   register for an event notification when the TCP connection enters or
   exits persist condition.  They can use the notification mechanism to
   implement their own scheme of deciding which persist connections to
   clear.  They can also suggest timeout or retry values to TCP."

This only proves that the draft indeed does mention about application's
role in assisiting the problem. Again the above purely falls into
"informational" category.

So, in summary : Clearly 1) above calls for some change in existing TCP
behaviour. So even though it is not strictly "on the wire" change ( like
someone was pointing out) it is a change to the TCP standards. Now, why
can't TCP be made robust which would help to address situations like
this documented in the draft?  Is there a resistance to change the RFC
1122 verbiage even though it is helpful to do so? It is matter a
providing a new timer in TCP ( I think Ted menioned it in one his
emails)

2) and 3)  doesn't need any change to the standards. They illustrate the
problem and provide solutions and suggestions.

Given that there seems to be an agreement that this is a problem, the
way I look at is 1) above calls for a change in the standards. 2) and 3)
are more informational purpose only.

FWIW, the current "intended status" of the draft stands as
informational. 

Thoughts/comments? Esp. there seems to to be some scope on re-wording
some sections of the draft to make the case more explicit, if that
helps?

-Anantha

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