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

> > 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.
> 
> That's not my assessment.

Ok.

> 
> It looks to me that there is considerable resistance to 
> standardizing the proposed solution, both on the grounds of 
> placement in the stack and on the limitations of the solution.  

Ok. That is the reason I pointed that, I believe the draft is not trying
to "standardize" the solution part and that is informational and
illustrational purpose only. It also mentions about the role of the
application, which is again needed to be treated as informational. Do
you see the need for making further clarifications that would make this
look better?.

> 
> [ For example, connections that advertise a large initial 
> window and then read a byte every (proposed timer size -1) 
> seconds will replicate the problem in the limit. Using timers 
> alone penalizes stopped connections when there is no resource 
> shortage. ]

Good point. I would think that this is a non-standard behavior, corner
case, why would an application do this in reality and how many times we
have seen such behaviors? I don't want lengthy thread on this, but this
is debatable, IMO.

> 
> Despite the fairly lively discussion, I have seen little 
> support for standardizing this mechanism in TCP, outside the 
> authors and their collaborators, and strong resistance from 
> the members of the WG.  
> 
> Again, I'm not assessing consensus officially here, but 
> that's how I see it.

Poin taken. But there seems to a confusion on what is being attempted to
be standardized versus what is illustrational/informational purpose
only. Just to re-state :

WHY WE BELIEVE THERE IS A NEED FOR STANDARD CHANGE/EXISTING STANDARD
CLARIFICATION ?
========================================================================
============
[Few people have echoed this question, the response below ]

I think there is a need for some standards change. Reason : I'll give an
example of a TCP proxy which doesn't have an application on top per se.
Now I would want to track the TCP connections ( yes there are several
ways to do this) and monitor the health of those, in particular those
that are "hanging" in persist state forever. I can use some timeout
inside TCP to kick off and kill those connections depending on some
policy, is this considered a voilation of RFC since RFC says " you MUST
keep these connections open as long as you receive ACKs?"  Someone can
point out that the TCP proxy is not RFC compliant since it was
"supposed" to keep these connections but terminated them, esp since
there is no application which owns these TCP connections on this box? 

I immediately realise that there may be some responses like " TCP
connection can be terminated anytime, so it should not be treated as
non-compliance of RFC 1122", Is this a fair enough response?. I am
confused, atleast I feel there is a need to say something like " TCP
MUST keep the connection open as long as it gets ACKS, however, if the
application OR a TCP implementation can abort this connection if it
determines by its own means that the connection needs to be taken off"..
I know.. I could have worded this better, but I hope my point is clear. 

Ok, if you think that there is nothing to be changed in TCP, but yet an
implementation trying to abort TCP connections that persist indefinitely
even though it is getting ACK's is fully compliant, then there is no
further debate on this point, I would think.

Can you and the other work group members clarify the above point?  

-Anantha

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