Re: [tsv-area] TANA BOF

[Roland Bless <[e-mail]>]

Hi Stanislav,

Stanislav Shalunov wrote:
> On Aug 1, 2008, at 4:26 AM, Roland Bless wrote:
>> It is not clear to me how "otherwise idle bandwidth"
>> can be made available for pure end-to-end transport
>> solutions, i.e., without differentiation in the
>> network itself.
> 
> On a technical level, we can definitely design and implement end-to-end
> congestion control that yields to (New)Reno -- or, in fact, to any
> loss-based congestion control.  In fact, I happen to have done just that
> for a particular application that currently uses up a larger fraction of
> bits on the Internet than any other app with the possible exception of
> HTTP.  Delay-based congestion control schemes yield to loss-based
> control quite often regardless of whether they are designed to do this
> simply because delay needs to increase to buffer size before loss occurs.

Hmm, ok I interpreted the statement for idle bandwidth obviously
differently.

>> a) probably it is easier to start deploying
>> RFC 3622 (http://tools.ietf.org/html/rfc3662)
>> in ISP networks than to design new
>> congestion control algorithms. All you need
>> is a DSCP, a codepoint classifier, a separate
>> queue and simple priority scheduling. CS(1)
>> DSCP=001000 was proposed for LE traffic.
> 
> Yes, we tried that
> (http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt -- note
> dates on the documents: March 2001 for qbss, June 2002 for
> draft-bless-diffserv-pdb-le-00.txt).  We may like or not like it, but
> scavenger has not been deployed.

I'm well aware of the QBSS definition and its usage in Internet2, but
our "Lower than best effort" idea was first published in September 1999
as draft-bless-diffserv-lbe-phb-00:
http://www.ietf.org/mail-archive/web-old/ietf-announce-old/current/msg05168.html
and the QBSS definition seems to have appeared after that.

> No, it is definitely not easier to upgrade the Internet than to design
> end-to-end algorithms that can be deployed by putting them into relevant
> applications.  This is a matter of deployment properties: to reach 80%
> deployment, one requires to change hundreds of millions of physical
> devices of thousands of different kinds, with virtually none of them on
> auto-update; the other requires to change a few pieces of software, all
> of them on auto-update.

Maybe its still not that obvious, e.g., shim6 vs. LISP have similar
arguments. ISPs seem to like schemes that allow them more control
over their net resources.

> The most congested links are uplinks of home connections.  We're not
> going to see the devices at their head ends changed any time soon.  When

In upstream direction: would it be the customer's DSL router for
instance? At least my router supports and uses different priorities
for VoIP and data packets and these devices can also be updated
via software...
For the downstream direction it would be the task of the ISP
to update the access/last-hop router.

> they are changed, they will likely not support whatever scheme we like
> until there's a good reason to.  Whereas we can deploy end-to-end
> congestion control, and it'll work across these links.

The interesting question for me is: what mechanisms are required in the
network itself to support such schemes? I guess that ECN - although a
nice and useful mechanism - has also and still deployment problems.

Best regards,
 Roland