[e2e] Why do we need TCP flow control (rwnd)?

[Jon Crowcroft]

on the duality of flow control & congestion control 
and the real "end" in end-to-end:

so i think keshav made a useful point - 
one could have a predictive rwnd window scheme -

for example, if a TCP receiver is delivering to a printer or to a screen, 
then there is a predicatable output
rate (modulo printer running out of paper, or human running out of eyes)

1.
so in this situation one can send a receive window that gets a sensible rate.
on the other hand, one could ALSO send a gratuitious ECN instead from the end point.

since the end point of the session (not transport) is a hop away
from the tcp end point (not such a rare occurance in these wireless spliced days:)
then this seems entirely the same as a router sending an ECN (or dropping a packet:)

2.
corrollary:
of course, routers could also change the receive window on returned packets 
(If the route was symmetric) and recompute the checksum appropriately,
instead of using precious ECN bits or dropping packets:)


mind you, a router has a harder task to predict things than a host.

so maybe the tcp/ip people got things roughly right, eh? 

j.