Sandra Gittlen wrote:
| In addition to the sheer size of the file, one issue is how to
| maintain a user's link for up to four hours. The Internet was
| not designed for such stateful connections.
Stateful connections?
Do you mean "long-lasting bulk-transfers"? If so, then, while
the current Internet is not optimal for them (in large part because
of the sheer amount of very short flows that in aggregate do not
do particularly good jobs of congestion avoidance, and because of
open loop non-congestion-avoiding traffic), it certainly was designed
to support them, and they can and do happen.
Multi-week TCP connections (ssh/telnet/X) across the Internet are nothing
very new, and they work just fine. Really large TCP bulk transfers lasting
hours and even days is nothing new in some places (supercomputer centres
and backup storage facilities come to mind).
Multi-hour multimedia stuff is not very new either -- people watching
IETF multicasts is not very new, and NANOG unleashed the concept of watching
several hours of realvideo too.
What is different here is that lots of people will be trying
to watch several hours of streaming realvideo all at once, and
there is a risk of something breaking down -- more likely the
realvideo servers won't cope with the load.
The really big pity is that TCP mode isn't the default; shoving
non-real-time realvideo into a TCP stream solves the worries about
realvideo's UDP-mode congestion avoidance not being _no more aggressive
than the congestion avoidance detailed in RFC 2001_ due to implementation
bugs or (intentional or accidental) protocol misdesign.
If, however, realvideo does RFC-2001-style congestion avoidance properly,
then the core of the network won't even notice Monday, since the
long-lived congestion-avoiding flows are "nicer" to bottlenecks
than the hordes of short-lived flows one normally sees when people
are surfing the web.
Sean.
