[e2e] Re: UDP vs. TCP distribution
Panos GEVROS
P.Gevros at cs.ucl.ac.uk
Thu Mar 8 13:04:13 PST 2001
Joe Touch writes:
|
|
|"David P. Reed" wrote:
|>
|> At 05:55 PM 3/7/01 +0100, Sean Doran wrote:
|> >It's not going to be cheaper to have an empty network than to have
|> >one with a bottleneck here and there.
|>
|> This presumes that customers want the lowest price regardless of
|> delay. Not true. And in any case, operating a network with queues mostly
|> full (which increases utilization) a lot of the time is great strategy if
|> you want to maximize profit when you are being paid by the byte (or by the
|> portal access rate).
|>
|> Most applications benefit from low queueing delay, so this isn't about QoS
|> differentiations. Only FTPs with no human in the loop want capacity with
|> no delay constraint.
|
|NTP wants it too.
|
|Capacity can also be used to mask latency, PROVIDED the variability
|in the feedback loop can be described (if not predicted). E.g., even
|FTPs with people in the loop work - you send the whole directory
|when the person does a "cd" (see Infocom 1995).
low delay (or jitter) is good but whether this should be the network design
goal is a different matter;
if capacity was not a constrain i would be willing to tolerate an extra delay
to download the whole "structure" (or a specific subset) of a web site and do
all the searching/browsing locally, also store it for future reference in case
i find it interesting enough, and save subsequent network accesses
the fact that only a fraction of the information downloaded would be of
interest may be irrelevant (because there are no capacity constrains)
of course this does not apply to using the web for transactions or dynamic
content,
so ftp-style transport may not be completely out of fashion yet,
it all depends on whether need for interactive experience or access to
information proves to be the killer app - but if bounded delay is a necessity
and customers are prepared to pay for it then we may be better of with
something where one directly "dials the web server"
Panos
More information about the end2end-interest
mailing list