Re: [rmcat] requirements (was Re: time to get active)

[Fu Jiantao <[e-mail]>]

Another concern for the requirement

There maybe sometimes UDP is blocked, and ICE may use TCP connection(see
http://tools.ietf.org/html/rfc4571 for how to use rtp/rtcp on TCP), this is
a practical user scenario, is there any consideration for this case? I'm
not sure whether this is in the scope of rmcat.

Thanks!

Jeromy


2013/2/28 ken carlberg <[e-mail]>

> well, perhaps I can get the ball rolling in terms of a headache to chew on
> :-)
>
> The second requirement in draft-jesup-rmcat-reqs-01.txt is...
>
>   2.   The algorithm must be fair to other flows, both realtime flows
>         (such as other instances of itself), and TCP flows, both long-
>         lived and bursts such as the traffic generated by a typical web
>         browsing session.  Note that 'fair' is a rather hard-to-define
>         term.
>
>         A.  The algorithm must not overreact to short-term bursts (such
>             as web-browsing) which can quickly saturate a local-
>             bottleneck router or link, but also clear quickly, and
>             should recover quickly when the burst ends.
>
>         B.  We will need make some evaluation of fairness, but deciding
>             what is "fair" is a tough question and likely to be
>             partially subjective, but we should specify some of the
>             inputs needed in order to select among algorithms and
>             tunings presented as options.
>
> however, the document does not have a definition of the term "fair" or
> "fairness".  And while the document points us to terminology in another
> draft (draft-ietf-rtcweb-overview-06.txt), this other draft doesn't even
> mention "fair" or fairness".  I think one nit is that the RMCAT
> requirements draft needs its own terminology section instead of pointing to
> another draft.
>
> And more importantly, I think we need to bite the bullet and decide what
> is "fair" / "fairness".  It just doesn't seem possible for us to say that
> the algorithms *must* be fair, but then punt in defining what is (or
> perhaps, what is not) fair.  And I'm definitely not meaning to beat up on
> the author, but rather ourselves.
>
> As a starting point, and in the context of real time apps, I don't think
> we need to be fair to a continual series of parallel short transaction
> flows.  Rather, I would prefer to be fair, or focus our attention, to
> longer transaction flows.
>
> thoughts?  Have I missed something?
>
> -ken
>
>
>
> On Feb 27, 2013, at 1:37 PM, "Eggert, Lars" <[e-mail]> wrote:
>
> > On Feb 27, 2013, at 19:35, Matt Mathis <[e-mail]> wrote:
> >> Did we perhaps address all of the hard problems in the charter process,
> so
> >> now there is nothing to controversial to chew on?
> >
> > I wish...
> >
> > Lars
>
>