Subject: [tsv-area] TANA BOF

From: Roland Bless <[email-masked]>
Date: Fri, 01 Aug 2008 13:26:36 +0200

Hi,

unfortunately I could not attend the TANA BOF personally.
But I have a question and some comments:
Item (1) says:
(1) A congestion control algorithm for less-than-best-effort
"background" transmissions, i.e., an algorithm that attempts
to scavenge otherwise idle bandwidth for its transmissions in
a way that minimizes interference with regular best-effort
traffic.

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. So from a pure transport endpoint
view, I can image to use a more aggressive congestion
control algorithm and getting less bandwidth than
normal TCP flows, but I cannot imagine to distinguish
between "normal" best-effort flows and lower-effort (LE)
flows without some support in the network.

Some comments:
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.

b) because LE traffic causes no harm to BE
traffic, ISPs can simply let all LE marked
traffic in. There is no need for additional
policing or re-marking at network boundaries.
Thus, it could easily work even across ISPs.

c) Even if LE is not deployed end-to-end everywhere
it is useful in domains where congestion occurs, so
complete end-to-end deployment is not necessary. At
least the end-to-end marking must be possible, but
point b) is a good reason to not clear DSCPs of
packets marked as LE DSCP already.

d) I can very well imagine that ISPs may fill up
their protection capacity (cf. RFC 3439
http://tools.ietf.org/html/rfc3439#section-6) with
lower-effort traffic, thus leveraging
unused capacity. Not clear, how well this works if
congestion is always at the access...

Regards,
 Roland

---

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 12:29:28 -0700

On Aug 1, 2008, at 4:26 AM, Roland Bless wrote:
> 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.

> 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

---

From: "Michael Welzl" <[email-masked]>
Date: Sun, 3 Aug 2008 10:12:06 +0200

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" <[email-masked]>
To: "Roland Bless" <[email-masked]>
Cc: "TSV Area" <[email-masked]>
Sent: Saturday, August 02, 2008 9:29 PM
Subject: Re: [tsv-area] TANA BOF

> Yes, we tried that
(http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt

---

From: Stanislav Shalunov <[email-masked]>
Date: Sun, 3 Aug 2008 03:14:21 -0700

> so I just don't know what will now happen...

We are preparing to post the minutes soon.

In a nutshell, the BoF was attended well, there was a lively  
discussion and many pointed questions and great ideas.  In the end,  
the room was unanimous in the preference to take up this work in a new  
WG, with a single person explicitly abstaining.  So it's up to the  
IESG now.

> and con's of different approaches, and commonalities among them

It would be great to have an overview of delay-based congestion  
control mechanisms as an input for the WG, if and when one is formed,  
in the form of a draft.  And, of course, you'd be the perfect person  
to write it.  Any chance you might?

--
Stanislav Shalunov

---

From: "Michael Welzl" <[email-masked]>
Date: Sun, 3 Aug 2008 12:19:50 +0200

> to write it.  Any chance you might?

Thanks  :-)   and yes. Not tomorrow, but in a couple of weeks, yes...

Best,
Michael

---

From: Roland Bless <[email-masked]>
Date: Mon, 04 Aug 2008 11:00:05 +0200

Hi Stanislav,

Stanislav Shalunov wrote:
> 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.

> (http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt -- note
> dates on the documents: March 2001 for qbss, June 2002 for

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.

> 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.

> 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

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