Re: [tcpm] Is this a problem?

In the spirit of keeping changes to TCP protocol minimal, how about
having the application specify a time limit via the socket API when TCP gets into this
 state and TCP cuts its indefinite wait down to this timeout? All states in the TCP
 protocol have some sort of a bound in terms of how long they will continue in that state 
(even EST. has a keepalive timeout tunable by app). Default behaviour continues to be 
current.

----- Original Message ----
From: Joe Touch <touch@ISI.EDU>
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
Cc: Lloyd Wood <L.Wood@surrey.ac.uk>; tcpm@ietf.org
Sent: Monday, November 5, 2007 4:41:47 PM
Subject: Re: [tcpm] Is this a problem?

MURALI BASHYAM wrote:
> Re-posting my response. 
> 
> Joe, apologies for mangling your response.
> 
> 
> The point is that it can be solved in TCP or at the transport layer
>  ALSO. 

It CAN. The question is whether it SHOULD be.

> It's as good a place
> if not better (from the co-ordination point of view and from the
 sender
>  state visibility points of view).
> Let me ask the question: Can you elaborate the reasons why doing it
 in
>  TCP is not a good idea? 

Basically because it CAN easily be done somewhere else. The
recommendation (Clark?) is "think twice before modifying TCP, then
don't" comes into play. IMO, that means "don't modify TCP unless you
absolutely have to".

TCP isn't supposed to be a convenient place to do things. It ought to
 be
lean, so you KNOW it'll work correctly.

> "A variety of solutions in a variety of places" is not a good
 position
>  to be in, we want the right
> solution in the one, correct place, with the least possible
 disruption
>  to the server community.

The right solution in the right place is a good rule too. I don't think
TCP is the right - i.e., best or most appropriate place - to do this.

I've noted in other emails that you're making a huge assumption about
using TCP for this - that all TCP connections are implemented in a
single, shared codebase (i.e., the kernel). They are not; that's not a
requirement of TCP.

I.e., every reason you have for wanting to do this in TCP is a good
reason to do this in the kernel, not TCP.

Joe

> ----- Original Message ----
> From: MURALI BASHYAM <murali_bashyam@yahoo.com>
> To: Joe Touch <touch@ISI.EDU>; Lloyd Wood <L.Wood@surrey.ac.uk>
> Cc: tcpm@ietf.org
> Sent: Monday, November 5, 2007 3:14:29 PM
> Subject: Re: [tcpm] Is this a problem?
> 
> 
> 
> 
> ----- Original Message ----
> From: Joe Touch <touch@ISI.EDU>
> To: Lloyd Wood <L.Wood@surrey.ac.uk>
> Cc: tcpm@ietf.org
> Sent: Monday, November 5, 2007 1:27:52 PM
> Subject: Re: [tcpm] Is this a problem?
> 
> 
> 
> 
> Lloyd Wood wrote:
> ...
>>> Yes, this is a problem for which a variety of solutions exist, and
>  for
>>> which a coordinated solution would be useful. No, that itself is
 not
>>> justification for assuming TCP is the place to do this.
>> try this thought on for size:
>>
>> "The need for congestion control is a problem for which a variety of
>> solutions exist, and for which a coordinated solution would be
>  useful.
> 
> I should have said "for which a variety of solutions in a variety of
> places - OS, application, API, protocol - exist..."
> 
> The primary point is that this isn't owned by communications layers.
> 
> 
> Joe
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www1.ietf.org/mailman/listinfo/tcpm
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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