Re: new web analysis page available
- View Source(duck)
> touch@...:thanks - I had that document in my cache to read.
> PS - a recent Internet Draft discussed the issue of TCP connection
> control, and aggregation across bottleneck links (although not the
> primary issue of the draft):
>This seems like a good thing to research; at the moment, I wouldn't
> The general conclusion we reached was that there is a good argument
> for controlling some of the parameters of multiple TCP connections
> to account for aggregate behavior, such as the graceful behavior
> over bottlenecks you describe.
> This is the case not only for multiple TCPs from a single host, but
> also for multiple TCPs from a set of hosts with a similar path.
even try to guess which destinations are "similar path" and which
destinations are special cases because of remote-system problems.
> This is a problem that should be addressed anyway; once addressed,If we could replace kernels at the same speed we replace browsers and
> the need for persistent HTTP weakens even further.
servers, yes, perhaps....in many ways I see p-HTTP as a reaction to the
fact that the Net with TCP is NOT a good environment for transaction-like
behaviour; what we can do to change that underlying fact, we should..
Looking forward to seeing further work in this area!
- View Source
>> touch@...:I think i was a touch negative about this last time i commented, which
>> PS - a recent Internet Draft discussed the issue of TCP connection
>> control, and aggregation across bottleneck links (although not the
>> primary issue of the draft):
>thanks - I had that document in my cache to read.
was uncalled for - the idea is good ....
to apply it to "similar" paths. one could just use cidr
prefixes.....if a destination path overlaps its likely
to share part of a prefix......
(or of course caches could literally trun traceroute to each other and
mark out paths that actualy are sharing links known to be