Subject: Re: Re[2]: [Tsvwg] VoIP and Congestive Collapes: QoS vs. Best Effort

From: Sally Floyd <[email-masked]>
Date: Thu, 03 Jul 2003 16:23:39 -0700

>Thanks a lot for clearing this up for me. I have a follow-on thought: I
>think that one aspect that the two drafts do share is a need for certain
>applications to abide by certain guidelines (for example, calls always
>terminate when packet loss becomes unacceptable, or video calls never
>exceed or their requested bandwidth utilization after being admitted.)
>
>Do you know if there is a generic way to enforce these requirements on
>applications? It seems to me that if the guidelines are not enforceable,
>there will be a tendency to descend into the "tragedy of the Commons" in
>all these scenarios. (Somebody will always hack a non-compliant version
>that ignores packet loss, and then distribute to the Internet User it as
>a "SuperPhone" or something like that.) Is this part of the larger
>"end-to-end vs. active core" debate? Is this out of the scope of the
>TSVWG?

I agree that the network itself has to offer incentives for flows
to use end-to-end congestion control (or more precisely, mechanisms
for discouraging flows traversing congested paths from not using
end-to-end congestion control.)  This argument was given in a paper
with Kevin Fall on "Promoting the Use of End-to-End Congestion
Control in the Internet" ("http://www.icir.org/floyd/end2end-paper.html"),
and a router mechanism was proposed in a paper with Ratul Mahajan
on "Controlling High-Bandwidth Flows at the Congested Router"
(http://www.cs.washington.edu/homes/ratul/red-pd/).  A related paper
on controlling aggregates from flash crowds or DDoS attacks is a
paper on "Controlling High Bandwidth Aggregates in the Network",
with a number of coauthors, available from "http://www.icir.org/pushback/".

Ratul and I now have an internet-draft-in-progress, not yet submitted,
on "Router Primitives for Protection Against High-Bandwidth Flows
and Aggregates" ("http://www.icir.org/floyd/papers/draft-flows-00c.txt").
Any feedback on this would be appreciated.  This draft is intended
to be rather generic, and to encourage the practical deployment of
any such mechanisms in routers, so that the Internet community can
learn more from the deployment of such mechanisms.  (The current
draft doesn't consider the specific case of VoIP traffic, but that
could easily be added.)

- Sally
http://www.icir.org/floyd/

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Cyrus Shaoul <[email-masked]>
Date: Thu, 03 Jul 2003 20:19:30 -0400

Sally, 

I will read all of the documents you pointed to, and try to post any
feedback to this list.

Thanks, 

Cyrus

On Thu, 03 Jul 2003 16:23:39 -0700
Sally Floyd <[email-masked]> wrote:

SF> >Thanks a lot for clearing this up for me. I have a follow-on thought: I
SF> >think that one aspect that the two drafts do share is a need for certain
SF> >applications to abide by certain guidelines (for example, calls always
SF> >terminate when packet loss becomes unacceptable, or video calls never
SF> >exceed or their requested bandwidth utilization after being admitted.)
SF> >
SF> >Do you know if there is a generic way to enforce these requirements on
SF> >applications? It seems to me that if the guidelines are not enforceable,
SF> >there will be a tendency to descend into the "tragedy of the Commons" in
SF> >all these scenarios. (Somebody will always hack a non-compliant version
SF> >that ignores packet loss, and then distribute to the Internet User it as
SF> >a "SuperPhone" or something like that.) Is this part of the larger
SF> >"end-to-end vs. active core" debate? Is this out of the scope of the
SF> >TSVWG?
SF> 
SF> I agree that the network itself has to offer incentives for flows
SF> to use end-to-end congestion control (or more precisely, mechanisms
SF> for discouraging flows traversing congested paths from not using
SF> end-to-end congestion control.)  This argument was given in a paper
SF> with Kevin Fall on "Promoting the Use of End-to-End Congestion
SF> Control in the Internet" ("http://www.icir.org/floyd/end2end-paper.html"),
SF> and a router mechanism was proposed in a paper with Ratul Mahajan
SF> on "Controlling High-Bandwidth Flows at the Congested Router"
SF> (http://www.cs.washington.edu/homes/ratul/red-pd/).  A related paper
SF> on controlling aggregates from flash crowds or DDoS attacks is a
SF> paper on "Controlling High Bandwidth Aggregates in the Network",
SF> with a number of coauthors, available from "http://www.icir.org/pushback/".
SF> 
SF> Ratul and I now have an internet-draft-in-progress, not yet submitted,
SF> on "Router Primitives for Protection Against High-Bandwidth Flows
SF> and Aggregates" ("http://www.icir.org/floyd/papers/draft-flows-00c.txt").
SF> Any feedback on this would be appreciated.  This draft is intended
SF> to be rather generic, and to encourage the practical deployment of
SF> any such mechanisms in routers, so that the Internet community can
SF> learn more from the deployment of such mechanisms.  (The current
SF> draft doesn't consider the specific case of VoIP traffic, but that
SF> could easily be added.)
SF> 
SF> - Sally
SF> http://www.icir.org/floyd/

Cyrus Shaoul
NTT Advanced Technology Corp.
[email-masked]
http://www.ntt-at.com/

---

From: "MORITA, Naotaka" <[email-masked]>
Date: Fri, 11 Jul 2003 10:23:52 +0900

Sally,

I have quickly reviewed the relevant documents.
My understanding is that your point is how to
coordinate best effort traffic regardless of TCP or UDP.
This is to avoid useless usage of the Internet.
One way is to impose self-control mechanism to each terminal
to reduce or to terminate the session
as is descirbed in IAB's concern.
Another way is to detect over-usage flows or aggregates at routers
to get rid of useless ones.

It seems reactive control and assumes single traffic class, i.e., best effort.

My point as is proposed in the following draft is
a kind of preventative control or admission control.
http://www.ietf.org/internet-drafts/draft-morita-tsvwg-pps-00.txt

The similarity is to rely on terminals behavior.

Naotaka

>http://www.icir.org/floyd/

----------------------------------
Naotaka MORITA, Senior Research Engineer, Supervisor
Network Service Systems Laboratories
Information Sharing Laboratory Group
NTT
3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN
Tel. +81-422-59-7464, ISDN-Fax +81-422-60-4012
E-mail: [email-masked]
MSN messenger: [email-masked]
NTT home page: http://www.ntt.co.jp/about/e/index.html