Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt

[Joe Touch <[e-mail]>]

Hi, Kasren,

[Michael]:
>>> For SCTP we allow for that Nagle is disabled on some streams (streams
>>> with high scheduling priority) and not on others. This is done exactly
>>> for this purpose.

[Joe]:
>> Sure, but that's also why it doesn't make sense for TCP.

> [Karen ] Yes and then also why Nagle off for TCP may give undesired and
> contra-productive results from a latency perspective.
> But then TCP applications may not typically have the application traffic
> patterns that gives these undesired latency effects of disabling Nagle.

The one thing we should have learned about TCP is to not make
assumptions about traffic patterns:

- (paraphrasing) after going idle, we need to decide whether to slam
CWND down or keep it open, and we need a "time since last sent"; we
don't have that timer, but because TCP traffic is mostly symmetric,
let's use "time since last received" (VJ88)
	Result: burst the entire CWND on the next HTTP request

- TCP congestion control can assume infinite sources
	Result: good performance for elephants but bad for mice
	or transaction sequences (web)

- TCP should not send large amounts of small packets because they create
congestion, e.g., Telnet (Nagle)
	Result: very bad delays on protocols where multibyte
	messages can straddle packet boundaries, e.g.,
	Telnet with Unicode, Web, etc.

	i.e., Nagle fails exactly for the kinds of uses
	it was intended

Joe