Subject: [Iccrg] [Fwd: [Sip] request for comments : Pre-Congestion Notification BOF]
From: [email-masked] (Kewin Stoeckigt)
Date: Sun Sep 17 05:13:52 2006

Hi,
I guess many of you have seen this?

Kewin

-------- Original Message --------
Subject: [Sip] request for comments : Pre-Congestion Notification BOF
Date: Thu, 14 Sep 2006 17:08:17 -0400
From: Anna Charny (acharny) <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, 
<[email-masked]>,	<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
CC: [email-masked]

Dear all,

We have submitted a request for Pre-Congestion Notification BOF at the
San Diego meeting.  The proposed BOF description, agenda, draft charter
and the problem statement draft are in the attached message below.

We welcome your feedback on any of these documents.  Please send your
comments to [email-masked].

Best Regards,
Anna Charny

________________________________

From: Anna Charny (acharny)
Sent: Thursday, September 14, 2006 4:51 PM
To: 'Magnus Westerlund'; 'Lars Eggert'
Cc: [email-masked]'; [email-masked]
Subject: Request for Pre-Congestion Notification BOF

Hello Lars and Magnus,

This message constitutes a formal request for Pre-Congestion
Notification BOF at the November IETF meeting in San Diego.

The BOF description and its proposed agenda are attached at the end of
this message.

If this BOF is approved,  we would like to request a two-hour slot that
avoids scheduling conflicts with the following working groups:  tsv,
nsis, sip, ieprep, ecrit, pwe3, dccp.

We also ask that you CC [email-masked] with your decision.

Of course we welcome any feedback you might have.

Best Regards,
Anna Charny

PCN BOF Description

The Pre-Congestion Notification (PCN)  BOF will address the problem of
how to provide scalable and resilient admission control and strong QoS
assurance while using packet marking techniques. Current attempts to
deliver QoS using only packet marking (e.g. DiffServ) are limited in the
level of QoS assurance that can be provided without substantial
over-provisioning. To improve the QoS assurance, PCN will add flow
admission control and flow pre-emption. In normal circumstances
admission control should protect the QoS of previously admitted flows.
In times of heavy congestion (for example caused by route changes due to
link or router failure) pre-emption of some flows should preserve the
QoS of remaining flows.

The overall approach will be based on a the concept of a PCN-Region,
within which the functionality is separated between the PCN-Interior
Node (PIN) and the PCN-End Node (PEN). The initial scope of the BOF will
be the case of a single DiffServ region, which maps to a PCN-Region.
PINs mark packet headers when their traffic is above a certain level, as
an early warning of incipient congestion ("pre-congestion"); this builds
on concepts from RFC 3168 "The Addition of Explicit Congestion
Notification to IP".  PENs monitor the markings and that information is
used to make flow admission control and pre-emption decisions. The
decisions could be made by the PENs or by a centralized system (which is
informed of the PCN information).

The BOF will address the need and the motivation for PCN work in the
context of IETF, provide a brief overview of prior PCN efforts and
related work,  and review open issues.  The BOF will also discuss the
scope of work and solicit feedback on the proposed charter.  Ultimately,
the goal of the BOF is to solicit community feedback on whether the
problem is clear and needs to be addressed, and consequently whether the
creation of a new PCN WG within the scope of the proposed charter is
warranted.

The draft charter is available from
http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt
<http://standards.nortel.com/pcn/PCN_draft_charter_v00.txt> .  The
problem statement and motivation for the PCN work is discussed in more
detail in draft-chan-pcn-problem-statement-00, which has been submitted
to IETF and is also available at
http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt
<http://standards.nortel.com/pcn/draft-chan-pcn-problem-statement-00.txt
> .

Proposed BOF agenda

1.  Agenda bashing  (5 min)
2.  Motivation and Problem Statement presentation  (15 min)
3.  Discussion of motivation and problem statement (30 min)
4.  Overview of prior PCN efforts, related work and open issues (15 min)
5.  Overview of the proposed charter (10 min)
6.  Discussion/bashing of the proposed charter (20 min)
7.  General discussion and poll on the WG creation (25 min)

-------------- next part --------------
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

From: [email-masked] (Wesley Eddy)
Date: Thu Sep 14 21:22:24 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <20060909143410.GI96464@verdi> <[email-masked]>
Message-ID: <[email-masked]>

On Sat, Sep 09, 2006 at 11:07:15AM -0700, Lachlan Andrew wrote:
> 
> A crude approach would be to respond to a loss rate  X  and corruption
> rate  Y  the same way as to  X ((X + 2Y) / (X+Y))  loss with no
> corruption.  For  X << Y  (an uncongested lossy link), this gives
> "loss" rate 2X and hence high potential throughput, but deferring to
> those with less loss.  If  X >> Y (a congested link) it gives  "loss"
> rate X+Y, treating corruption as loss.
> 
> This can be implemented by a lookup table, the same way as HS-TCP is.

In CETEN, we acheived something similar to this by varying the
multiplicative decrease factor between 1/2 and 1, as a function of the
ratio of the corruption loss rate to the total loss rate:

http://www.icir.org/mallman/papers/ceten-ccr-oct2004.ps
http://www.icir.org/mallman/papers/eten-comnet.ps

The idea behind CETEN was to get around the thorny issue of determining
whether particular losses are due to congestion or corruption and to
utilize only a network-provided estimate for the probability of a
corruption loss.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Wed Sep 13 22:28:32 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
References: <[email-masked]> <[email-masked]>
Message-ID: <002a01c6d770$66b9cf00$0200a8c0@fun>

> I think it would be interesting to try to come up with two things
> 1. What we know. Known 'good' approaches - i.e. whats common to the  
> proposals out there.

but what exactly shall we expect to learn from / accomplish with this?
I mean, we can write an overview, looking at commonalities ... to
be concrete, I think this can be something like "delay has been used
as a congestion measure in ... Vegas, FAST, ... it has the following
advantages, the following disadvantages..."  ... and so on and so forth.

That might be nice, but I'm having a hard time imagining that this
will take us anywhere. Also, such overviews exist - how much
should the overview differ from, say, this one:
http://transport.internet2.edu/transport-design-space.pdf
or the others in our Wiki?

And what would it accomplish that the others don't?

Cheers,
Michael

From: [email-masked] (S. Keshav)
Date: Wed Sep 13 22:20:00 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Sep 13, 2006, at 11:22 AM, Michael Welzl wrote:

>
>
> With the recent discussions on the list, I'm wondering -
> instead of doing this overview of congestion control
> approaches out there, why don't we develop an overview
> of open issues in congestion control? There seem to be
> some interesting issues that the IETF would want to
> see solved, but the researcher community isn't really
> looking at.
>
> Developing a simple list of such open issues could
> be a nice goal for the meeting.
>
> What do you think?
>
> Cheers,
> Michael
>
Michael,
	I think it would be interesting to try to come up with two things
1. What we know. Known 'good' approaches - i.e. whats common to the  
proposals out there.
2. What we don't know. Open issues.

A survey of approaches should only be the first step in trying to  
summarise good approaches.

keshav

From: [email-masked] (Lachlan Andrew)
Date: Wed Sep 13 18:14:40 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi> <[email-masked]> <20060912170245.GN96464@verdi> <[email-masked]>
Message-ID: <[email-masked]>

Greetings,

I tried posting the below, but it bounced due to the attachment.  The
attachment is at
<http://netlab.caltech.edu/~lachlan/optimum_erased.pdf>.

Cheers,
Lachlan

On 12/09/06, Lachlan Andrew <[email-masked]> wrote:
> Greetings,
>
> On 12/09/06, John Leslie <[email-masked]> wrote:
> > Lachlan Andrew <[email-masked]> wrote:
> >
> > > The well-developed theory of Network
> > > Utility Maximisation tells us that *** the amount by which the source
> > > should back off when there is corruption increases with the amount of
> > > congestion (signalled by loss).***
> >
> >    Citation?
>
> The attached is a very rough sketch of my argument.  It's probably
> full of holes, and I'd be happy to hear about them.
>
> > > Michael is right that the incremental
> > > utility gained by getting corrupt data is smaller than that from
> > > un-corrupt data.
> >
> >    But we don't know how much smaller...
>
> True.  We can treat the corrupt data as worthless (as Michael later
> suggested), which gives an upper bound on the amount we should back
> off.
>
> >    Regardless, I'd aim for enough redundancy to render the utility of
> > corrupted data "close enough" to the utility of uncorrupted data.
>
> That may also be hard to determine, and may involve too much
> redundancy.  Consider the case of a small fraction of packets beging
> corrupted, but the corruption is almost complete.  To make those
> almost-useless packets useful, we would need massive redundancy.
> However, even the uncorrupted packets must incur that redundancy
> (since we don't know in advance which will be corrupted).  If the
> redundancy exceeds the rate of corrupt packets, we're better off just
> treating them as erasures.
>
> > > A crude approach would be to respond to a loss rate  X  and corruption
> > > rate  Y  the same way as to  X ((X + 2Y) / (X+Y))  loss with no
> > > corruption.
> >
> >    But what crystal ball do you consult to choose the constant (2)?
> > It seems rather low to me for many near-real-time uses...
>
> *grin*  I said it was crude :)  The attached sketch gives a first-cut
> systematic derivation.  It seems that for Reno, the "right" approach
> is simply to scale the window down by a factor of
> (1-corruption_rate),  assuming we treat corruption as erasure.  I
> haven't got around to thinking about partial corruption yet...
>
> > > Congestion control that responds to "hetereogeneous" signals, like
> > > loss and corruption, have begun to be studied by Kevin Tang
> > > <http://netlab.caltech.edu/~aotang/pub/07/ton2007.pdf>.
> >
> >    This paper seems to be concerned with stability -- an important
> > concern, to be sure, but I didn't read any indication that his chosen
> > conditions were _necessary_ for stability.
>
> It mentions stability, but the focus is on the equalibrium rate
> allocations.  Normally, we can say for a given set of TCP flows what
> their equilibrium share of the rate will be.  In "heterogeneous"
> networks, it can depend intrinsically on the order of their arrival.
> That isn't just "slow convergence to fairness", but multiple stable
> rate allocations.  (That is why sufficient conditions for stability
> are of interest here, rather than necessary conditions.)  That is
> important if we are trying to work out what control will give
> different flows some desired share of the bandwidth.  This may be too
> "theoretical" to be of interest to ICCRG, but I thought it may be of
> some use.

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (Michael Welzl)
Date: Wed Sep 13 18:08:16 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <20060912172140.GO96464@verdi>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi> <[email-masked]> <[email-masked]> <20060912172140.GO96464@verdi>
Message-ID: <[email-masked]>

> > So, to put it more precisely: my question was about the
> > correct response of a transport endpoint that would be
> > notified about corruption when the receiver cannot use
> > corrupt data.
> > 
> > This can be done with the DCCP Data Checksum option, and
> > also the mechanism described in this draft:
> > http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-05.txt
> > 
> > In this case, increasing redundancy is no option.
> > 
> > So, under these circumstances, what is the right response
> > for the transport sender?
> 
>    There are still two cases:
> 
> 1. The data will need to be retransmitted;
> 2. The data would no longer be useful after a retransmission delay.

I don't see any difference between these two cases. After all,
the goal is to transfer as much data as possible without "harming"
the network. This intention is there, no matter if we retransmit
or not.

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Wed Sep 13 17:46:56 2006
Subject: [Iccrg] Meeting agenda (really! :-) )
Message-ID: <[email-masked]>

Hi all,

In the meantime, I received some (but not enough!) emails
from folks who would like to attend the meeting.

We also have the first talks on our agenda - these would
be short presentations with a few slides, and an ensuing
discussion:

Tom Phelan: "DCCP, TFRC and Open Problems in
Congestion Control for Media Applications"

Lars Eggert: thoughts about TERNLI / ICCRG (title TBD)
(this is tentative - Lars will probably know in January
whether he can attend or not - he'll do the presentation
if he can come)

With the recent discussions on the list, I'm wondering -
instead of doing this overview of congestion control
approaches out there, why don't we develop an overview
of open issues in congestion control? There seem to be
some interesting issues that the IETF would want to
see solved, but the researcher community isn't really
looking at.

Developing a simple list of such open issues could
be a nice goal for the meeting.

What do you think?

Cheers,
Michael

From: [email-masked] (John Leslie)
Date: Tue Sep 12 20:09:52 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi> <[email-masked]>
Message-ID: <20060912174734.GP96464@verdi>

Michael Welzl <[email-masked]> wrote:
> On Sat, 2006-09-09 at 16:34, John Leslie wrote:
>> Michael Welzl <[email-masked]> wrote:
>>> On Fri, 2006-09-08 at 19:38, Wesley Eddy wrote:
>>>> 
>>>> 1) congestion control when striping data over multiple paths...
>> 
>> There is a "correct" thing to do; but I don't claim it's practical:
>> have the two routers surrounding the split maintain it as a single virtual
>> path, with a single congestion behavior.
> 
> If it's SCTP, I think that the question on the table is the
> correct reaction in the transport end system (where we can't
> assume that routers do what you suggest).
> 
> In this case, I think that SCTP should treat each path
> just like TCP would (if you would use one TCP connections
> per path).
> 
> What would be the reason to do anything else?

   I see none, unless we have reason to believe the congestion occurs
on a portion of the path shared by both. I'd further argue that in the
absence of "simultaneous" congestion on two paths, there _is_ no reason
to believe the congestion is on a shared portion.

   If, OTOH, we _know_ the congestion is on a shared portion, it could
be argued we're _able_ to treat it as a single virtual path. Frankly,
I don't agree; but were we able to, the question of fairness would be
a purely local one, so I'd call it a configuration option, and spend
my mental effort worrying only whether our overall reaction to congestion
will be fast enough.

>> Anything less than this will tend to break the model on which congestion
>> control is built. :^(
> 
> Why?

   Imprecise answer!

   More exactly, I meant that we use an already-broken model which assumes

- congestion is the only source of packet loss;
- the next packet will follow the same path;
- therefore (collectively) we must immediately reduce the sending rate.

and that switching paths in midstream shows up its brokenness.

   I wasn't thinking SCTP at all: if I were, I would have thought of it
as separate connections, not as striping.

--
John Leslie <[email-masked]>

From: [email-masked] (John Leslie)
Date: Tue Sep 12 19:44:16 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi> <[email-masked]> <[email-masked]>
Message-ID: <20060912172140.GO96464@verdi>

Michael Welzl <[email-masked]> wrote:
> 
> So, to put it more precisely: my question was about the
> correct response of a transport endpoint that would be
> notified about corruption when the receiver cannot use
> corrupt data.
> 
> This can be done with the DCCP Data Checksum option, and
> also the mechanism described in this draft:
> http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-05.txt
> 
> In this case, increasing redundancy is no option.
> 
> So, under these circumstances, what is the right response
> for the transport sender?

   There are still two cases:

1. The data will need to be retransmitted;
2. The data would no longer be useful after a retransmission delay.

   In the first, you will need to stress the network by retransmitting.
At a minimum, you need to debit the retransmission against the allowable
transmission rate, ane I'd argue for an additional decrement in the
allowable transmission rate -- perhaps subtracting what would be added
for a successful packet.

   In the second, Lachlan would argue for decreasing the transmission
rate, based on the assumption that there must be some higher-utility
potential use. I am unconvinced, so far.

>>>> It may be the right thing to reduce the rate by less than
>>>> in the normal congestion case, but by how much...?
>>>
>>>  Wrong question!
>> 
>> No, it is the right question.  The well-developed theory of Network
> 
> It was an imprecise question  :)

   Thank you.

>> An important question is whether all applications should be
>> arbitrarily assigned the same utility (as is implicitly done by all
>> TCP variants), or the utility should reflect the actual application's
>> benefit from getting a certain amount of data at a given level of
>> corruption.  Since different application gain vastly different amounts
> 
> Let's assume equal utilities for now, just to keep things
> simple. In principle, addressing applications which would
> also benefit from delivery of some corrupt data in addition
> to the above would also be interesting, but let's start
> simple for now.

   I'm not sure there's anything useful we _could_ do without assigning
different utilities...

--
John Leslie <[email-masked]>

From: [email-masked] (John Leslie)
Date: Tue Sep 12 19:27:12 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi> <[email-masked]>
Message-ID: <20060912170245.GN96464@verdi>

Lachlan Andrew <[email-masked]> wrote:
> On 09/09/06, John Leslie <[email-masked]> wrote:
>> Michael Welzl <[email-masked]> wrote:
>> 
>>> This inspires me to mention one more:
>>>
>>> The correct reaction to corruption.
>>
>> Actually, there is one: increase the reundancy of coding.
>> This actually will result in a hopefully-slight _increase_ in bandwidth
>> demand. This is _not_ wrong!
> 
> Good point.  However, bear in mind that it is the role of the source
> to do source coding, rather than "100% reliable" channel coding, which
> is best done at the physical/link level.

   Point well taken: I was not differentiating by role, which may have
been the intent of the question.

   But forget not that in _any_ real-time application, our end-to-end
model imposes on each end the responsibility to determine the appropriate
amount of redundancy.

   "100% reliable" is telco-think. That model has been rejected in the
Internet design. It's better to use a more precise term here. (I'm not
proposing one. though.)

   There is a channel-level responsibility for _some_ level of reliability,
but it's not clear what that level might be. We'd _like_ ethernet-level
reliability, but that's not always appropriate. (Lachlan is quite correct
to assign this responsibility to link level or below.)

> One purpose of allowing the network to deliver corrupt packets is if
> the ultimate application can withstand some corruption (like
> transmitting perceptual data).

   Almost any near-real-time application will be better off receiving
the corrupted packets. (This implies some alternative to TCP.)

> In that case, the application should balance more concise source
> coding against the increased channel coding to maximise the user's
> perception *given* the network resources.  It does not immediately
> tell us whether we should increase or decrease the bandwidth.

   True. I merely meant that (hopefully-small) increases in network
traffic can improve reliability of transit for a given raw data rate.

>> It is always "wrong" to fill a pipe with traffic which serves no useful
>> purpose. Alas, there's often no way to determine whether it's useful.
> 
> Exactly.  Getting corrupted video is arguably more "useful" than
> getting reliable spam.  It should be up to the application to
> determine what is useful.

   I agree. (But of course TCP doesn't do this.)

>>> It may be the right thing to reduce the rate by less than
>>> in the normal congestion case, but by how much...?
>>
>> Wrong question!
>>
>> Sufficient redundancy can repair the corruption (and, of course,
>> eliminate the need for retransmission).
> 
> No, it is the right question.  The well-developed theory of Network
> Utility Maximisation tells us that *** the amount by which the source
> should back off when there is corruption increases with the amount of
> congestion (signalled by loss).***

   Citation?

> The issue of whether different applications should get more or less
> bandwidth is an issue of choosing the "utility" the application
> obtains by getting the data.  Michael is right that the incremental
> utility gained by getting corrupt data is smaller than that from
> un-corrupt data.

   But we don't know how much smaller...

> That means that the "optimal" solution will cause that rate to decrease
> *provided* there is other traffic to take up the slack (indicated by
> loss).  If there is no loss, the source should not back off due to
> corruption.

   I certainly agree with the last sentence.

   TCP backs off as if the corruption was congestion. Assuming any
reasonable percentage of TCP traffic, I doubt there's any need for other
traffic to back off. But perhaps there may be cases where congestion
loss continues despite ongoing corruption. I had presumed that reacting
to the _actual_ congestion loss would be sufficient -- and, to tell truth,
I can't thing of a useful way to determine how much additional backing
off would be right if that weren't sufficient.

   Regardless, I'd aim for enough redundancy to render the utility of
corrupted data "close enough" to the utility of uncorrupted data.

> A crude approach would be to respond to a loss rate  X  and corruption
> rate  Y  the same way as to  X ((X + 2Y) / (X+Y))  loss with no
> corruption.  For  X << Y  (an uncongested lossy link), this gives
> "loss" rate 2X and hence high potential throughput, but deferring to
> those with less loss.  If  X >> Y (a congested link) it gives  "loss"
> rate X+Y, treating corruption as loss.

   But what crystal ball do you consult to choose the constant (2)?
It seems rather low to me for many near-real-time uses...

> Congestion control that responds to "hetereogeneous" signals, like
> loss and corruption, have begun to be studied by Kevin Tang
> <http://netlab.caltech.edu/~aotang/pub/07/ton2007.pdf>.

   This paper seems to be concerned with stability -- an important
concern, to be sure, but I didn't read any indication that his chosen
conditions were _necessary_ for stability.

--
John Leslie <[email-masked]>

From: [email-masked] (Michael Welzl)
Date: Tue Sep 12 08:47:12 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <20060909143410.GI96464@verdi>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi>
Message-ID: <[email-masked]>

On Sat, 2006-09-09 at 16:34, John Leslie wrote:
> Michael Welzl <[email-masked]> wrote:
> > On Fri, 2006-09-08 at 19:38, Wesley Eddy wrote:
> >> 
> >> 1) congestion control when striping data over multiple paths.  Issues
> >>    here involve mechanisms for detecting the degree of independence between
> >>    paths, and identifying shared-congestion on the common portions of
> >>    multiple paths.  These have come up in the IETF in the context of SCTP.
> >>    After shared congestion is identified, what is the proper response?
> 
>    There is a "correct" thing to do; but I don't claim it's practical:
> have the two routers surrounding the split maintain it as a single virtual
> path, with a single congestion behavior.

If it's SCTP, I think that the question on the table is the
correct reaction in the transport end system (where we can't
assume that routers do what you suggest).

In this case, I think that SCTP should treat each path
just like TCP would (if you would use one TCP connections
per path).

What would be the reason to do anything else?

Despite the fact that multiple TCP connections are more
aggressive and a single one, congestion control is really
a per-path function and should be treated as such (i.e.
for TCP, in an ideal world, the congestion manager should
be used   :)   ).

>    Anything less than this will tend to break the model on which congestion
> control is built. :^(

Why?

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Tue Sep 12 08:32:16 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi> <[email-masked]>
Message-ID: <[email-masked]>

> > > The correct reaction to corruption.
> >
> >    Actually, there is one: increase the reundancy of coding.
> >    This actually will result in a hopefully-slight _increase_ in bandwidth
> > demand. This is _not_ wrong!
> 
> Good point.  However, bear in mind that it is the role of the source
> to do source coding, rather than "100% reliable" channel coding, which
> is best done at the physical/link level.  One purpose of allowing the
> network to deliver corrupt packets is if the ultimate application can
> withstand some corruption (like transmitting perceptual data).
> 
> In that case, the application should balance more concise source
> coding against the increased channel coding to maximise the user's
> perception *given* the network resources.  It does not immediately
> tell us whether we should increase or decrease the bandwidth.

Many different things are mixed here - the questions "who
reacts", and "will corrupt data be delivered?"...

So, to put it more precisely: my question was about the
correct response of a transport endpoint that would be
notified about corruption when the receiver cannot use
corrupt data.

This can be done with the DCCP Data Checksum option, and
also the mechanism described in this draft:
http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-05.txt

In this case, increasing redundancy is no option.

So, under these circumstances, what is the right response
for the transport sender?

> >    It is always "wrong" to fill a pipe with traffic which serves no useful
> > purpose. Alas, there's often no way to determine whether it's useful.
> 
> Exactly.  Getting corrupted video is arguably more "useful" than
> getting reliable spam.  It should be up to the application to
> determine what is useful.

Again, I think that this has to do with my imprecise question.
In the setting I described above (the one which my question
should have addressed), it's clear that the received packet
is of no use if it's erroneous, except that it enables the
receiver to inform the sender of its reception.

> > > It may be the right thing to reduce the rate by less than
> > > in the normal congestion case, but by how much...?
> >
> >    Wrong question!
> >
> >    Sufficient redundancy can repair the corruption (and, of course,
> > eliminate the need for retransmission).
> 
> No, it is the right question.  The well-developed theory of Network

It was an imprecise question  :)

> Utility Maximisation tells us that *** the amount by which the source
> should back off when there is corruption increases with the amount of
> congestion (signalled by loss).*** It is up to the corruption-tolerant
> application whether it uses the bandwidth for redundancy or reduced
> compression.
> 
> The issue of whether different applications should get more or less
> bandwidth is an issue of choosing the "utility" the application
> obtains by getting the data.  Michael is right that the incremental
> utility gained by getting corrupt data is smaller than that from
> un-corrupt data.  That means that the "optimal" solution will cause
> that rate to decrease *provided* there is other traffic to take up the
> slack (indicated by loss).  If there is no loss, the source should not
> back off due to corruption.
> 
> A crude approach would be to respond to a loss rate  X  and corruption
> rate  Y  the same way as to  X ((X + 2Y) / (X+Y))  loss with no
> corruption.  For  X << Y  (an uncongested lossy link), this gives
> "loss" rate 2X and hence high potential throughput, but deferring to
> those with less loss.  If  X >> Y (a congested link) it gives  "loss"
> rate X+Y, treating corruption as loss.

That looks very interesting! How did you obtain this equation -
what's the rationale behind it?

> This can be implemented by a lookup table, the same way as HS-TCP is.
> 
> An important question is whether all applications should be
> arbitrarily assigned the same utility (as is implicitly done by all
> TCP variants), or the utility should reflect the actual application's
> benefit from getting a certain amount of data at a given level of
> corruption.  Since different application gain vastly different amounts

Let's assume equal utilities for now, just to keep things
simple. In principle, addressing applications which would
also benefit from delivery of some corrupt data in addition
to the above would also be interesting, but let's start
simple for now.

> of utility from corrupt date, I would suggest having two classes of
> utility (i.e., two responses to congestion) -- one for TCP-like
> behaviour which seeks 100% reliability and one for perceptual
> applications which do their own redundancy tradeoff.
> 
> Congestion control that responds to "hetereogeneous" signals, like
> loss and corruption, have begun to be studied by Kevin Tang
> <http://netlab.caltech.edu/~aotang/pub/07/ton2007.pdf>.

Great pointer, thanks!

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Sat Sep  9 20:29:04 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <20060909143410.GI96464@verdi>
References: <[email-masked]> <[email-masked]> <[email-masked]> <20060909143410.GI96464@verdi>
Message-ID: <[email-masked]>

Greetings all,

Executive summary:  the amount by which the source should back off
when there is corruption increases with the amount of congestion
(signalled by loss).

Detailed arguments (plus propsed response) below:

On 09/09/06, John Leslie <[email-masked]> wrote:
> Michael Welzl <[email-masked]> wrote:
> > This inspires me to mention one more:
> >
> > The correct reaction to corruption.
>
>    Actually, there is one: increase the reundancy of coding.
>    This actually will result in a hopefully-slight _increase_ in bandwidth
> demand. This is _not_ wrong!

Good point.  However, bear in mind that it is the role of the source
to do source coding, rather than "100% reliable" channel coding, which
is best done at the physical/link level.  One purpose of allowing the
network to deliver corrupt packets is if the ultimate application can
withstand some corruption (like transmitting perceptual data).

In that case, the application should balance more concise source
coding against the increased channel coding to maximise the user's
perception *given* the network resources.  It does not immediately
tell us whether we should increase or decrease the bandwidth.

> > There seems to be some agreement (and, by the way, I
> > also personally agree  :-)   ) that the (not so uncommon)
> > idea of a sender which would not reduce its rate at all
> > in response to corruption is not the right way to do it.
>
> > Here's a (somewhat artificial) example explanation: you may
> > have a sender which generates a lot of traffic, yet doesn't
> > deliver anything useful - yet, this sender may cause other
> > senders to reduce their rates, even though they would
> > not experience any corruption whatsoever.
>
>    It is always "wrong" to fill a pipe with traffic which serves no useful
> purpose. Alas, there's often no way to determine whether it's useful.

Exactly.  Getting corrupted video is arguably more "useful" than
getting reliable spam.  It should be up to the application to
determine what is useful.

> > It may be the right thing to reduce the rate by less than
> > in the normal congestion case, but by how much...?
>
>    Wrong question!
>
>    Sufficient redundancy can repair the corruption (and, of course,
> eliminate the need for retransmission).

No, it is the right question.  The well-developed theory of Network
Utility Maximisation tells us that *** the amount by which the source
should back off when there is corruption increases with the amount of
congestion (signalled by loss).*** It is up to the corruption-tolerant
application whether it uses the bandwidth for redundancy or reduced
compression.

The issue of whether different applications should get more or less
bandwidth is an issue of choosing the "utility" the application
obtains by getting the data.  Michael is right that the incremental
utility gained by getting corrupt data is smaller than that from
un-corrupt data.  That means that the "optimal" solution will cause
that rate to decrease *provided* there is other traffic to take up the
slack (indicated by loss).  If there is no loss, the source should not
back off due to corruption.

A crude approach would be to respond to a loss rate  X  and corruption
rate  Y  the same way as to  X ((X + 2Y) / (X+Y))  loss with no
corruption.  For  X << Y  (an uncongested lossy link), this gives
"loss" rate 2X and hence high potential throughput, but deferring to
those with less loss.  If  X >> Y (a congested link) it gives  "loss"
rate X+Y, treating corruption as loss.

This can be implemented by a lookup table, the same way as HS-TCP is.

An important question is whether all applications should be
arbitrarily assigned the same utility (as is implicitly done by all
TCP variants), or the utility should reflect the actual application's
benefit from getting a certain amount of data at a given level of
corruption.  Since different application gain vastly different amounts
of utility from corrupt date, I would suggest having two classes of
utility (i.e., two responses to congestion) -- one for TCP-like
behaviour which seeks 100% reliability and one for perceptual
applications which do their own redundancy tradeoff.

Congestion control that responds to "hetereogeneous" signals, like
loss and corruption, have begun to be studied by Kevin Tang
<http://netlab.caltech.edu/~aotang/pub/07/ton2007.pdf>.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (John Leslie)
Date: Sat Sep  9 16:55:44 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <20060909143410.GI96464@verdi>

Michael Welzl <[email-masked]> wrote:
> On Fri, 2006-09-08 at 19:38, Wesley Eddy wrote:
>> 
>> 1) congestion control when striping data over multiple paths.  Issues
>>    here involve mechanisms for detecting the degree of independence between
>>    paths, and identifying shared-congestion on the common portions of
>>    multiple paths.  These have come up in the IETF in the context of SCTP.
>>    After shared congestion is identified, what is the proper response?

   There is a "correct" thing to do; but I don't claim it's practical:
have the two routers surrounding the split maintain it as a single virtual
path, with a single congestion behavior.

   Anything less than this will tend to break the model on which congestion
control is built. :^(

>> 2) congestion control for mobile nodes and within mobile networks
>>    (either NEMO or Connexion by Boeing style).  What are the scenarios
>>    where existing mechanisms are valid, and under what conditions do
>>    they break down?  What is the space of solutions (e.g. you could do
>>    things like TCP RLCI, or more radical things)?  What is sensible for
>>    MANET-style networks?

   This one is hard! Congestion characteristics will change at each
handoff. The best we can hope for is to pass the characteristics to one
or both endpoints. (Interestingly, this shares some features of the split
case above, but none of the stability.)

> Thanks Eddy! This inspires me to mention one more:
> 
> The correct reaction to corruption.

   Actually, there is one: increase the reundancy of coding.

   This actually will result in a hopefully-slight _increase_ in bandwidth
demand. This is _not_ wrong!

> There seems to be some agreement (and, by the way, I
> also personally agree  :-)   ) that the (not so uncommon)
> idea of a sender which would not reduce its rate at all
> in response to corruption is not the right way to do it.

   TCP, of course, will throttle back _and_ retransmit as often as needed.
That will actually make _more_ bandwidth available than the ideal.

> Here's a (somewhat artificial) example explanation: you may
> have a sender which generates a lot of traffic, yet doesn't
> deliver anything useful - yet, this sender may cause other
> senders to reduce their rates, even though they would
> not experience any corruption whatsoever.

   It is always "wrong" to fill a pipe with traffic which serves no useful
purpose. Alas, there's often no way to determine whether it's useful.
Were it known to be useless, the sender should of course scale back.

   This brings up the "broadcast-like" usages found today. These are
incorrect uses of the Internet -- trying to make it something it isn't.
Most of the time, these should probably behave more like time-shifting
uses: when there is a genuine need for "real-time" data, they should
mimic VoIP.

   There are, of course, genuine "multicast" uses -- such as conferencing.
Multicast is its own research issue...

> It may be the right thing to reduce the rate by less than
> in the normal congestion case, but by how much...?

   Wrong question!

   Sufficient redundancy can repair the corruption (and, of course,
eliminate the need for retransmission). If retransmission _is_ needed,
I would agree that transmission rate should be reduced -- at a minimum
the retransmission must be counted against the allowed rate. I would
personally like to see an additional decrease to match the increase
which would be needed for sufficient redundancy, but this may not be
worth trying to specify.

   As for the question of correlation of congestion to corruption: this
assuredly does happen in wireless. But I'm not sure it's practical to do
anything about it. It can come either from noise due to more data being
sent or be due to a sender being configured to push the envelope on
signal-to-noise permissible for a higher data rate. The first is too hard
to measure (if indeed it's even related to anything we're involved in);
the second needs to be punished more severely than we can do.

--
John Leslie <[email-masked]>

From: [email-masked] (Michael Welzl)
Date: Fri Sep  8 20:26:56 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, 2006-09-08 at 19:38, Wesley Eddy wrote:
> On Wed, Sep 06, 2006 at 07:19:09PM +0200, Michael Welzl wrote:
> > Dear all,
> > 
> > Let's see what could be discussed at the planned ICCRG meeting.
> > Topics we recently discussed on the list are:
> > 
> > - congestion control definition
> > - taxonomy of congestion control approaches
> > - issues surrounding explicit feedback
> > - expanding the application of congestion control beyond file transfer
> > - applicability of TMRG drafts to congestion control research
> > 
> > Any volunteers who would want to do a short presentation on
> > one of these topics, or a similar one, and then hopefully
> > get a discussion going?
> > 
> > Are there topics which you'd consider more interesting? I'm
> > looking for your input!
> >
> 
> The odds of me attending the meeting are exceedingly slim due to a date
> conflict, but here are a couple of other topics that I think are sort of
> unanswered questions the group might want to consider:
> 
> 1) congestion control when striping data over multiple paths.  Issues
>    here involve mechanisms for detecting the degree of independence between
>    paths, and identifying shared-congestion on the common portions of
>    multiple paths.  These have come up in the IETF in the context of SCTP.
>    After shared congestion is identified, what is the proper response?
> 
> 2) congestion control for mobile nodes and within mobile networks
>    (either NEMO or Connexion by Boeing style).  What are the scenarios
>    where existing mechanisms are valid, and under what conditions do
>    they break down?  What is the space of solutions (e.g. you could do
>    things like TCP RLCI, or more radical things)?  What is sensible for
>    MANET-style networks?
>  
> I may be wrong, but if there are good and well-accepted answers to these
> questions, I don't think they are widely known.

Thanks Eddy! This inspires me to mention one more:

The correct reaction to corruption.

>From RFC 4340:

The combination of reduced checksum coverage and Data
Checksum options may let endpoints report packets as corrupt rather
than dropped, using Data Dropped options and Drop Code 3 (see Section
11.7).  This may eventually benefit applications.  However, further
research is required to determine an appropriate response to
corruption, which can sometimes correlate with congestion.  Corrupt
packets currently incur a loss response.

There seems to be some agreement (and, by the way, I
also personally agree  :-)   ) that the (not so uncommon)
idea of a sender which would not reduce its rate at all
in response to corruption is not the right way to do it.

Here's a (somewhat artificial) example explanation: you may
have a sender which generates a lot of traffic, yet doesn't
deliver anything useful - yet, this sender may cause other
senders to reduce their rates, even though they would
not experience any corruption whatsoever.

It may be the right thing to reduce the rate by less than
in the normal congestion case, but by how much...?

This question also applies to a current SCTP draft, btw.

Cheers,
Michael

From: [email-masked] (Wesley Eddy)
Date: Fri Sep  8 20:03:28 2006
Subject: [Iccrg] Meeting agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Sep 06, 2006 at 07:19:09PM +0200, Michael Welzl wrote:
> Dear all,
> 
> Let's see what could be discussed at the planned ICCRG meeting.
> Topics we recently discussed on the list are:
> 
> - congestion control definition
> - taxonomy of congestion control approaches
> - issues surrounding explicit feedback
> - expanding the application of congestion control beyond file transfer
> - applicability of TMRG drafts to congestion control research
> 
> Any volunteers who would want to do a short presentation on
> one of these topics, or a similar one, and then hopefully
> get a discussion going?
> 
> Are there topics which you'd consider more interesting? I'm
> looking for your input!
>

The odds of me attending the meeting are exceedingly slim due to a date
conflict, but here are a couple of other topics that I think are sort of
unanswered questions the group might want to consider:

1) congestion control when striping data over multiple paths.  Issues
   here involve mechanisms for detecting the degree of independence between
   paths, and identifying shared-congestion on the common portions of
   multiple paths.  These have come up in the IETF in the context of SCTP.
   After shared congestion is identified, what is the proper response?

2) congestion control for mobile nodes and within mobile networks
   (either NEMO or Connexion by Boeing style).  What are the scenarios
   where existing mechanisms are valid, and under what conditions do
   they break down?  What is the space of solutions (e.g. you could do
   things like TCP RLCI, or more radical things)?  What is sensible for
   MANET-style networks?
 
I may be wrong, but if there are good and well-accepted answers to these
questions, I don't think they are widely known.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Wed Sep  6 19:40:00 2006
Subject: [Iccrg] Meeting agenda
Message-ID: <[email-masked]>

Dear all,

Let's see what could be discussed at the planned ICCRG meeting.
Topics we recently discussed on the list are:

- congestion control definition
- taxonomy of congestion control approaches
- issues surrounding explicit feedback
- expanding the application of congestion control beyond file transfer
- applicability of TMRG drafts to congestion control research

Any volunteers who would want to do a short presentation on
one of these topics, or a similar one, and then hopefully
get a discussion going?

Are there topics which you'd consider more interesting? I'm
looking for your input!

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Fri Sep  1 10:31:44 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <20060901011340.GH2333@verdi>
References: <[email-masked]> <[email-masked]> <20060807163623.GC62046@verdi> <[email-masked]> <20060901011340.GH2333@verdi>
Message-ID: <[email-masked]>

> > That is why we talk about updating every 60 seconds or there about
> 
>    Oscillation is a problem of phase shifting, not delay time. It's the
> damping inherent in averaging which helps here.
> 
>    The question should be _how_ to route around congestion. Clearly,
> it's not always possible; but when it is, we could be doing a _lot_
> better!

While I agree with your statement, I'd also like to add that
there might also be other things that we could do with
congestion information that is carried in routing updates -
in which case the oscillation problem wouldn't concern us.

Cheers,
Michael

From: [email-masked] (John Leslie)
Date: Fri Sep  1 03:35:44 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <20060807163623.GC62046@verdi> <[email-masked]>
Message-ID: <20060901011340.GH2333@verdi>

Doan B. Hoang <[email-masked]> wrote:
> John Leslie wrote:
> 
>> Oscillation is a serious problem in routing. In a research environment,
>> it can be measured and appropriate damping can be calcultated. In actual
>> deployment, oscillation must be avoided.
>  
> There are few problems with carrying additional information in routing 
> messages:
> 1) It takes so many years before a routing protocol is adopted (look at 
>    OSPF)

   That's Somebody Else's Problem.

> 2) Many folks have tried to put QoS parameters in the Link State Vector 
>    so that they can find optimal QoS routing. The QoS optimal routing
>    has been proved a NP-complete problem.

   I don't agree that's the problem we need to solve.

>    Even [if] you do not care about optimality or NP-complete, it still
>    does not work in reality (stability reason).

   We really ought to know by now how to control oscillation!

> 3) Oscillation problem was investigated in the early ARPANET, where the 
>    traffic-sensitive link parameters are updated and reported every
>    1/3 of a second (see one of McQuillan's papers), the result was
>    unstable and loops.

   ... which surprised us at the time, but shouldn't surprise us now!

> That is why we talk about updating every 60 seconds or there about

   Oscillation is a problem of phase shifting, not delay time. It's the
damping inherent in averaging which helps here.

   The question should be _how_ to route around congestion. Clearly,
it's not always possible; but when it is, we could be doing a _lot_
better!

--
John Leslie <[email-masked]>

From: [email-masked] (John Leslie)
Date: Fri Sep  1 03:33:36 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <20060901005329.GG2333@verdi>

Doan B. Hoang <[email-masked]> wrote:
> 
> One should consider per interface queue length rather than numerous
> individual queues.

   One can reasonably consider queue length for as many queues as you
maintain; but it's hard to justify maintaining very many queues.

> I believe that it is better to deal with congestion control at two 
> levels (at least): the network level and the transport level.
> The transport level never works well if the network level cannot handle 
> congestion properly.

   Actually, transport level works amazingly well under those conditions;
but it seems obvious that _some_ limits to network congestion are needed.

> For example, TCP traffic cannot compete with UDP traffic since there is 
> no cooperation between sources.

   There is a very important issue here; but that's not the right way to
state it: TCP traffic suffers badly when it competes with traffic which
does not practice "TCP-friendly congestion control".

> Furthermore, per-TCP flow congestion control is not scalable (ECN
> modification for example).

   Per-flow TCP congestion control is perfectly scalable when practiced
end-to-end. :^)

> Current congestion control at the network level (IP) is implicit and 
> does not contain adequate information for sources to react.

   I'm not sure what you mean. Current congestion control drops packets
at some congestion level, and that's exactly adequate information for
sources to react.

   Our problems are imperfect transmission of congestion information and
sources which fail to react.

> We are considering Explicit Rate, per-Ingress-Egress congestion control 
> for traffic classes (DSCP-like) plus associated admission control.

   This sounds interesting. Any mechanism which propagates congestion
information back towards the source holds promise of improving the
adaptation to congestion.

> This information will be used by the transport protocol to handle its
> own flow.

   Again, I'm not sure what you mean...

--
John Leslie <[email-masked]>

From: [email-masked] (Doan B. Hoang)
Date: Fri Sep  1 02:25:20 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tony Li wrote:

>Michael,
>
>Would a former router vendor do?
>
>A complete answer to your query would probably be more lengthy than what
>you really intended, so I'm going to be relatively terse.  Please feel
>free to ask me to expound where it's of interest.
>
>Modern high end router design has a 100% pure hardware data path.  While
>some instantiations actually have some degree of programmability, there
>is nothing that looks like a general purpose processor executing
>arbitrarily complicated code anywhere near the average packet.
>
>Thus, what's realistic is extremely limited: any solution must not
>require significant state, as there is typically very little high speed
>memory available; any solution must also be relatively simple, both from
>a computational complexity point of view, as well as from a
>verifiability perspective.  Any in-band packet modifications (e.g., RFC
>3168 ECN) are problematic because packet header examination and
>modification is typically done on the ingress side of the router, prior
>to the actual switching of the packet.  For scalability reasons,
>maintaining full active queue state on the input side of the system is
>challenging, as the queues only truly exist on the output side.
>Out-of-band notification (e.g., ICMP source quench) is a security
>nightmare.  Interaction with MPLS needs to be thought through and fully
>specified.
>
>Finally, on the non-technical front, the system replacement cycle is on
>the order of five years, and router customer and router vendors need to
>be presented with a direct and immediate business case for any
>modifications.
>  
>
On this point I agree with Jon Crowcroft that any congestion control 
scheme must be inherent
and ready when it is required. Finding a good congestion control scheme 
should not start only
when the vendors need it (by yesterday not tomorrow).
See a discussion paper by Jon Crowcroft and his group:

Crowcroft, J., Hand, S., Mortier, R., Roscoe, T., Warfield, A. (2003). 
QoS's Downfall: At the bottom, or not at all! _ACM SIGCOMM 2003 
Workshop_. Karlsruhe, Germany.

Doan

>I don't mean to sound discouraging, but any changes at this point would
>be challenging.
>
>Regards,
>Tony
>
>
>  
>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]] On Behalf Of Michael Welzl
>>Sent: Sunday, August 06, 2006 1:09 AM
>>To: iccrg
>>Subject: [Iccrg] Explicit feedback
>>
>>Hi,
>>
>>There is no doubt that explicit feedback from routers is useful
>>for a congestion control mechanism - this has been illustrated
>>by mechanisms like XCP and Quickstart (and several others).
>>
>>Yet, such mechanisms are critical because they require additional
>>work in routers. So what is realistic? How much extra effort
>>can one really assume from routers, when the scalability of
>>a mechanism must not be constricted? And how should the
>>provision of such feedback be specified - e.g. with pseudocode,
>>as in the appendix of the XCP paper, or something else...?
>>
>>This kind of knowledge is missing in the congestion control
>>landscape. Perhaps we can we make a change here.
>>
>>Presumably, the best answers would come from folks who
>>work for router vendors - do we have some here? If so,
>>could you please comment?
>>
>>Cheers,
>>Michael
>>
>>_______________________________________________
>>Iccrg mailing list
>>[email-masked]
>>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>
>>    
>>
>
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  
>

-- 
Doan B. Hoang, PhD			
URL: http://research.it.uts.edu.au/arn

From: [email-masked] (Doan B. Hoang)
Date: Fri Sep  1 02:10:24 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <20060807163623.GC62046@verdi>
References: <[email-masked]> <[email-masked]> <20060807163623.GC62046@verdi>
Message-ID: <[email-masked]>

John Leslie wrote:

>Tony Li <[email-masked]> wrote:
>  
>
>>IGRP has carried loading information since the early 80's.  Similarly,
>>one of the early Arpanet routing algorithms (SPREAD, I think) carried
>>load information.  Both were used in routing decisions and resulted in
>>oscillation.
>>    
>>
>
>   Oscillation is a serious problem in routing. In a research environment,
>it can be measured and appropriate damping can be calcultated. In actual
>deployment, oscillation must be avoided.
>  
>
There are few problems with carrying additional information in routing 
messages:
1) It takes so many years before a routing protocol is adopted (look at 
OSPF)
2) Many folks have tried to put QoS parameters in the Link State Vector 
so that they can find
optimal QoS routing. The QoS optimal routing has been proved a 
NP-complete problem. Even you
do not care about optimality or NP-complete, it still does not work in 
reality (stability reason).
3) Oscillation problem was investigated in the early ARPANET, where the 
traffic-sensitive link
parameters are updated and reported every 1/3 of a second (see one of 
McQuillan's papers),
the result was unstable and loops.
That is why we talk about updating every 60 seconds or there about

Doan

>  
>
>>The control loop time constant for routing protocols is simply too long
>>to be useful at conveying high frequency congestion event notification.
>>However, very low frequency utilization information might be possible.
>>I would tend to consider this first for IGPs, given their more limited
>>scope than BGP.
>>    
>>
>
>   IGPs are a simpler problem, certainly; but oscillation must be avoided
>there as well.
>
>   IGRP is an excellent starting point to understand the issues. It
>correctly identifies the issues of latency, bandwidth, load, and
>reliability. More research, IMHO, would help determine a better way
>of evaluating these and adjusting forwarding decisions.
>
>- Latency is a minimal delay to reach the origin of the route. It
>  obviously can be incremented by the (known) latency of each step
>  along the way (not to be confused with the actual delay experienced
>  by packets being queued along the way). I would suggest floating-point
>  units of seconds.
>
>- Bandwidth is the upper limit of bytes per second. It obviously can
>  be evaluated and reduced if necessary at each forwarding step. I
>  would suggest floating-point units of bytes per second.
>
>- Load can be expressed either as bytes per second used or bytes per
>  second unused. I would suggest the latter. I think it's clear that
>  this should be a long-term average, say one hour. Further, I suggest
>  that it be two (floating-point) numbers, such as mean and standard
>  deviation.
>
>- Reliability is a harder problem. Research is needed. As a starting
>  point, I'd think in terms of reporting each failure to forward,
>  with coding for the reason (discard, loss of carrier, etc.) and a
>  floating-point estimate of bytes failed per bytes sent. Clearly
>  such reports should not be propagated very far unless they show
>  a substantial change in reliability.
>
>   All of these numbers should be reported based upon the actual path
>that a router will use for packets matching that route. We will have
>to support environments in which different classes of packets are
>routed differently. I assume routing updates will identify classes
>to which the reported route applies. I also expect that multiple
>paths may be used (without changing the routing updates sent).
>
>   "Reliability", IMHO, should not be confused with route withdrawl.
>If "reliability" actually reaches zero, obviously the route should
>have been withdrawn; I would guess that "reliability" below 90%
>might well justify route withdrawl, but perhaps research would show
>otherwise. I only mean to suggest a benefit from reporting reduced
>reliability appreciably before a route would be withdrawn.
>
>   It's not clear what action a router "should" take when reduced
>reliability is reported. In practice, we've found dropping one
>packet per thousand to signal congestion can adequately maintain
>basically dependable connections via end-to-end congestion avoidance.
>I suspect some improvement might be possible through queueing and
>redundancy (to avoid the need for retransmission), but I have no
>data to back that up.
>
>   (I hope it's clear I'm not talking about deploying changes to
>backbone routers: I'm talking about research to find the sort of
>changes which might be worth trying to deploy in the future.)
>
>--
>John Leslie <[email-masked]>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  
>

-- 
Doan B. Hoang, PhD			
URL: http://research.it.uts.edu.au/arn

From: [email-masked] (Doan B. Hoang)
Date: Fri Sep  1 01:57:36 2006
Subject: [Iccrg] Explicit feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tony Li wrote:

> 
>
>  
>
>>>verifiability perspective.  Any in-band packet 
>>>      
>>>
>>modifications (e.g., RFC
>>    
>>
>>>3168 ECN) are problematic because packet header examination and
>>>modification is typically done on the ingress side of the 
>>>      
>>>
>>router, prior
>>    
>>
>>>to the actual switching of the packet.  For scalability reasons,
>>>maintaining full active queue state on the input side of 
>>>      
>>>
>>the system is
>>    
>>
>>>challenging, as the queues only truly exist on the output side.
>>>      
>>>
>>This part interests me: why is this a problem?
>>Is it because separate hardware pieces are involved on the ingress
>>and egress side, where every such piece (chip) would do all the
>>necessary work for one link only?
>>    
>>
>
>
>Typical high end routers now are designed for tens or hundreds of
>thousands of queues.   Some systems are probably well over a million.
>The egress side has queue information that it needs to propagate in
>real-time to the ingress side over an unreliable medium.  This is
>certainly solvable, but it comes at a price in bandwidth and mechanism,
>multiplied by scale and timeliness.  Justifying that cost is, IMHO, very
>hard.
>
>Tony
>
>  
>
Monitoring queue length this way does not scale and very expensive. One 
should consider
per interface queue length rather than numerous individual queues.

I believe that it is better to deal with congestion control at two 
levels (at least): the network
level and the transport level.
The transport level never works well if the network level cannot handle 
congestion properly.
For example, TCP traffic cannot compete with UDP traffic since there is 
no cooperation
between sources. Furthermore, per-TCP flow congestion control is not 
scalable (ECN
modification for example).
Current congestion control at the network level (IP) is implicit and 
does not contain adequate
information for sources to react.

We are considering Explicit Rate, per-Ingress-Egress congestion control 
for traffic classes (DSCP-like)
plus associated admission control. This information will be used by the 
transport protocol to handle its
own flow.

Doan

>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>  
>

-- 
Doan B. Hoang	
URL: http://research.it.uts.edu.au/arn