Re: Client header for connection speed info

I have looked at it, and I plan on attending the BOF scheduled for the
next IETF to discuss it further with the document authors.  The
authors certainly seem to intend it as a metadata exchange model for
information about objects rather than connections, but it may be that
they see the connection as an attribute of an instance of an object.
If so, it might carry enough information to allow an optimization of
content based on knowledge about the connection.

I think, though, that there is an architectural issue here that goes
beyond optimizing particular connections.  Historically, the Internet
model had a fairly strict sense of what devices had to know about
specific packet interchanges.  As a connectionless system layered on
multiple underlying connections, the basic sense was that only the
origin and destination nodes had to know about any particular
interchange.  The intermediate devices had to know how to examine a
packet and send it someplace sensible, but did not have to keep track
of connection state or any other information.

As optimization has increased in the intermediate devices, things like
route caching and CEF made it likely that a packet sent from an
intermediate device onward would go the same place each time, but it
remains a choice made by the intermediate device based on its
knowledge of the routes to the destination.  That means that the edge
devices cannot know with any certainty whether a packet sent will
travel the same path as the packet before it or the packet after it.
That creates a problem for end-to-end bandwidth measurements and in
using such measurements to determine what content should be sent
to a specific destination.  To have real visibility into this process
for the participants in an interchange would require an enormous change
in the architecture of the system, as well as a lot of additional
traffic and code.

The contrary argument to this is that the end-to-measurements are not
necessary, because the constraining factor for a very large number of
cases is the link speed of the client "last mile" (the dial up modem
speed, dsl throughput, or whatever).  Since the client can be
configured to know and report that, it can be used as an indicator.
This is true, but presents a problem where the last mile isn't the
constraint (true where there are trans-oceanic links are present, for
example), or where the requestor does not wish to have that constraint
used as a limiting factor.  

				regards,
					Ted Hardie





> 
> Since the traffic is generated by the servers, for the most part, shouldn't 
> the server and its protocols be aware of bandwidth problems and self-limit 
> the feed?  Has anyone taken a look at the blocks protocol, submitted by 
> invisible worlds, as a potential fit?
> 
>                  http://mappa.mundi.net/Internet-Drafts/
> 
> If an upgrade command is sent along then why wouldn't this be an 
> appropriate protocol?
> Before I get slammed, I realize that clients have to be able to understand 
> this new protocol and that it is not a perfect fit for everyone.  I'm just 
> asking if anyone has looked at this and could it be applied in certain cases?
> 
> At 08:37 PM 3/2/00 , hardie@equinix.com wrote:
> >conneg's work is bounded to negotiation related to content features
> >and does not include a registered feature tag for something like
> >bandwidth or link speed.  While it would be possible to use the conneg
> >syntax to create a "bandwidth" feature, I believe that doing so would
> >not ultimately benefit content negotiation.  A device with a very low
> >link speed may still be used to render very complex content; it
> >increases the download time, but this may not matter to the end user
> >(especially if the download is background or unattended).  I would
> >suggest using MIME types and features to indicate the breadth of
> >available content and/or the user's capabilities and preferences; the
> >set intersection logic allowed by the conneg syntax is fairly powerful
> >in its ability to match capabilities and content features.  This
> >approach will also catch the case of high-link speed/low capability
> >devices (like modem-equipped PDAs).
> 
> ===========================================================
> Kevin J. Dyer				     Draper Laboratory  MS 35
> Email: <kdyer@draper.com>		     555 Tech. Sq.
> Phone: 617-258-4962			     Cambridge, MA 02139
> FAX: 
> 617-258-2061                                   http://www.draper.com 
> 
> ---------------------------------------------------------------------------- 
> ------------------------------------------
> 	    _/_/_/_/    _/          _/  _/  _/        _/     _/_/_/_/
> 	   _/      _/   _/_/     _/_/  _/  _/_/     _/   _/
> 	  _/       _/  _/ _/   _/ _/  _/  _/  _/   _/    _/_/_/
> 	 _/      _/   _/  _/ _/  _/  _/  _/    _/ _/            _/
> 	_/_/_/_/   _/    _/    _/  _/  _/        _/  _/_/_/_/
>         Data Management & Information Navigation Systems
> =========================================================== 
>

Received on Monday, 6 March 2000 13:45:01 UTC