Re: [tsv-area] TANA BOF

["Michael Welzl" <[e-mail]>]

Speaking of TANA,

May I ask what the outcome of the BOF was? There are no
minutes in the proceedings so far, and I couldn't come to Dublin,
so I just don't know what will now happen...

I think TANA is a great activity, and I agree with your points
below about a new end-to-end congestion control mechanism.
Surely you're aware that quite a bit of work already exists in
this direction (well you say that you did some of your own),
the first activity of the group (if it has come into being?!) should
therefore be to examine this work IMHO, looking for pro's
and con's of different approaches, and commonalities among them

Cheers,
Michael


----- Original Message ----- 
From: "Stanislav Shalunov" <[e-mail]>
To: "Roland Bless" <[e-mail]>
Cc: "TSV Area" <[e-mail]>
Sent: Saturday, August 02, 2008 9:29 PM
Subject: Re: [tsv-area] TANA BOF


> 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.
>
> > 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.
>
> 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.
>
> 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 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.
>
> Thank you for the comments,
>
> -- Stas
>
> --
> Stanislav Shalunov
>
>
>