Re: [rmcat] Fwd: New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt

Fu Jiantao <fuji246@gmail.com> Wed, 06 March 2013 13:12 UTC

Return-Path: <fuji246@gmail.com>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880F921F8936 for <rmcat@ietfa.amsl.com>; Wed, 6 Mar 2013 05:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTjGZn2fTL5C for <rmcat@ietfa.amsl.com>; Wed, 6 Mar 2013 05:12:41 -0800 (PST)
Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id E79B421F8994 for <rmcat@ietf.org>; Wed, 6 Mar 2013 05:12:34 -0800 (PST)
Received: by mail-pb0-f52.google.com with SMTP id ma3so5994849pbc.11 for <rmcat@ietf.org>; Wed, 06 Mar 2013 05:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6EJ23LBfTOX+lX/LXNV9Po/8edLa9IS02wrQR6pHE2w=; b=gtY5KkJfzrkIV+z2vQdlXhqWOpqLuAnpWNgqbHCUqRn1qzoP+98zOA3Z/LuV6dX9Oc MDkxaICsZQkNs6Jxghas+sIlmKmo/KE5kXTQ6Hc9su4GkF2nw25v7jVW1xLtBGWGebhB gR1iWlLg8KFLY7zm5/3V0PHDSOJRnqwiC0o9i0kG708V/Hh+0cUvZd8SW6FTVEkz7gL2 OSn83V5DsnJw/kwJkZCNb07fXnJoXZtoTIslkgJjZw0EdgZ/ANgMCAaqijf1OsgM8XmI uDh3eeBJZAyjwqI7cdR3PYnvQurKKLAkiuky6eCaRn9r1ji+iWdDvT7qzvj44S0cVtjY G9ag==
MIME-Version: 1.0
X-Received: by 10.68.211.225 with SMTP id nf1mr45907049pbc.104.1362575554543; Wed, 06 Mar 2013 05:12:34 -0800 (PST)
Received: by 10.70.33.3 with HTTP; Wed, 6 Mar 2013 05:12:34 -0800 (PST)
In-Reply-To: <D9FEAB13-A45C-4F74-B38B-5428B2C0B002@ifi.uio.no>
References: <20130119095614.17091.17595.idtracker@ietfa.amsl.com> <D9FEAB13-A45C-4F74-B38B-5428B2C0B002@ifi.uio.no>
Date: Wed, 06 Mar 2013 21:12:34 +0800
Message-ID: <CAKmxLjW7cOp-Xryb6tqDX=F=0XaP2LcUQ+c6xVYveFfDNjj2Cg@mail.gmail.com>
From: Fu Jiantao <fuji246@gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Content-Type: multipart/alternative; boundary="e89a8ff1c090ea883204d741572e"
Cc: "rmcat@ietf.org WG" <rmcat@ietf.org>
Subject: Re: [rmcat] Fwd: New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmcat>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2013 13:12:42 -0000

Hi Michael,

   Following are my comments:

  1. multiplexing make the SBD simple, but it may take more effort for
classification in QoS. delay and loss correlations works fine for UDP
connection, but for having both TCP and UDP connections in police
network(drop overlimit packets directly), it seems no easy way to do SDB.

  2. the new_S_CR seems not updated with new_CR in step 3, from the
examples, it should be the new_S_CR in the last round, and I guess new_S_CR
is the common state variable sharing in each round, only so it can be used
to avoid only make S_CR increase at once.

  3. The example algorithm will only update flow(i)'s state when its cc
changed the calculated rate, other flow's state is leave untouched. There
are other algorithms, for example, updates all flow's state when flow(i)'s
state changed. What's the reason to prefer the first one, and I think the
second one is more reasonable and simple to implement.

Thanks

Jeromy


2013/1/19 Michael Welzl <michawe@ifi.uio.no>

> Hi all,
>
> See below the announcement of a draft I just posted, to address the
> milestone on "identifying and controlling groups of flows".
> I'm curious to hear your thoughts!
>
> Cheers,
> Michael
>
>
> Begin forwarded message:
>
> > From: internet-drafts@ietf.org
> > Subject: New Version Notification for draft-welzl-rmcat-coupled-cc-00.txt
> > Date: January 19, 2013 10:56:14 AM GMT+01:00
> > To: michawe@ifi.uio.no
> >
> >
> > A new version of I-D, draft-welzl-rmcat-coupled-cc-00.txt
> > has been successfully submitted by Michael Welzl and posted to the
> > IETF repository.
> >
> > Filename:      draft-welzl-rmcat-coupled-cc
> > Revision:      00
> > Title:                 Coupled congestion control for RTP media
> > Creation date:         2013-01-19
> > WG ID:                 Individual Submission
> > Number of pages: 14
> > URL:
> http://www.ietf.org/internet-drafts/draft-welzl-rmcat-coupled-cc-00.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-welzl-rmcat-coupled-cc
> > Htmlized:
> http://tools.ietf.org/html/draft-welzl-rmcat-coupled-cc-00
> >
> >
> > Abstract:
> >   When multiple congestion controlled RTP sessions traverse the same
> >   network bottleneck, it can be beneficial to combine their controls
> >   such that the total on-the-wire behavior is improved.  This document
> >   describes such a method for flows that have the same sender, in a way
> >   that is as flexible and simple as possible while minimizing the
> >   amount of changes needed to existing RTP applications.
> >
> >
> >
> >
> > The IETF Secretariat
> >
>
>