Re: [tcpm] Is this a problem?

[Joe Touch <[e-mail]>]

Mahesh Jethanandani wrote:
> Caitlin,
> 
> Caitlin Bestler wrote:
>>
>> This is indeed a problem. I’m just not convinced it’s a transport problem.
>> Only the application layer has enough information to know when a client’s
>> behavior is abusive and/or suspicious.
>>
> Applications if anything have less knowledge than TCP on why a
> connection is not making progress. In this particular case, HTTP could
> not make a distinction between a connection not making progress because
> of congestion in the network or because the client is advertising zero
> window. 

If an application - or host - has limited resources, it doesn't matter
why a connection isn't making progress.

> And yet all Apache can do is to reset the connection after a
> fixed amount of time. Again, HTTP may know how many of its connections
> are in the stuck state, it will not know how many FTP connections are
> seeing the same issue or how seriously constrained the system is.

There is no rule that TCP connections "see" each other per se; from
within a single connection, an implementation could be able to access
only a single connection's state.

And, ultimately, a system is constrained when it runs out of processor
or memory - which have nothing to do necessarily with the connections in
progress. I.e., an application can ask the OS - or the OS can tell the
app - when such limitations come into play anyway.

> We have found that a fixed timeout also does not work. It is easy to
> guess and work around as we did with our client program.
> 
> The solution has to be adaptive to the condition which in this case
> involves TCP and applications have little knowledge of the state of all
> of TCP connections.
>>
>> The transport layer should remain
>> militantly ignorant of these matters.
>>
> When it impacts TCP's ability to function, I can hardly see that being
> ignorant will help.

You're declaring that someone who sends a zero receive window longer
than you expect to be noncompliant. There's nothing in the spec that
says that a TCP connection has to make forward progress in any fixed
timescale - even based on RTTs. This has allowed TCP to proceed over
shared links where less than one segment succeeds per RTT - e.g.,
congested transatlantic links. My concern is that this modification will
disable correct behavior in the corner cases.

Not all TCP connections must - or should - work only for the common cases.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm