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.