Subject: RE: [AVT] Feedback on draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt from Dallas IETF meeting ( Was Draft minutes from Dallas)

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 24 Apr 2006 15:31:52 -0700

Randell,

Thanks for your response. Please find some more comments inline.

> Randell Jesup [mailto:[email-masked]] writes:
> Colin Perkins <[email-masked]> writes:
> >RTCP feedback messages for packet delay adjustments
> >
> >    draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt
> >
> >    AC Mahendran presented the initial proposal for a packet delay
CCM
> >    message, to control packet delivery in time varying wireless
links.
> >    This allows receivers to provide direct feedback to the sender to
> >    control packet sending delay.
> >
> >    Steve Casner, Joerg Ott and Roni Even noted that sender based
delay
> >    adaptation is not useful in many scenarios, and that rate
adaptation
> >    is typically required (i.e. the aim is not to reduce buffering
delay
> >    at the sender, but rather queuing delay in the network, which can
> only
> >    be done by reducing the sending rate).
> 
> Absolutely.
> 
> >    They noted that it is not clear that the existing measurement
reports
> >    can't be used to control rate adaptation, and that it's not clear
> that
> >    this mechanism would see any more use for adaptation than
existing
> >    metrics.
> 
> Existing reports are not real-time enough and the information in them
is
> too generic to work in this case - over a long period it might
identify
> the bandwidth available, but it wouldn't respond well to variations,
and
> it would take too long to converge.
> 
> >    AC responded that the delay was the best measurement they had
found,
> >    and that the existing metrics don't handle handle wireless very
well,
> >    so he considers this appropriate.  Magnus Westerlund disagreed,
> >    commented that what we are discussing is congestion control.
> 
> While AC is partly correct, I agree with Magnus - this is an issue of
> congestion control, though slightly different than the scenario
typically
> modelled in academia.  They model (usually) fixed-bandwidth links with
> varying traffic.  The wireless scenario is a
> variable-bandwidth/variable-delay(?) link, perhaps with varying
traffic.
> Where the term "congestion control" is misleading (though not
incorrect)
> is
> that the channel might have no competing streams, but still have
variable
> bandwidth and delay that needs to be compensated for.
> 
> >    In that space we need to consider how successful earlier delay
based
> >    proposals, such as TCP Vegas, have been. In addition we should
> >    consider if we should develop to ad-hoc congestion control for
RTP,
> >    rather than developing general purpose solutions at the transport
> >    layer.
> 
> Also, current congestion control methods rely strongly on packet-drop
as
> an
> indirect signal of congestion.  That method is probably not
appropriate
> for
> a wireless situation (where packet-drop might be due to channel loss,
or
> congestion/channel-bandwidth). 

I think the point you made is already very well known and understood by
this community. I would like to point you to section13, RFC1368.
RFC3168, Sec 13 states "With the increased deployment of applications
and transports sensitive to the delay and loss of a single packet (e.g.,
realtime traffic, short web transfers), depending on packet loss as a
normal congestion notification mechanism appears to be insufficient (or
at the very least, non- optimal)"

> Also, it's possible (and worth
> investigating) if channel-delay gives an "early-warning" signal of
> problems
> in this case, before packets are dropped.  (This depends on how
aggressive
> the routers/channels are in dropping versus queuing - a
general-purpose
> wireless link might keep deep queues to compensate for occasional
> dropouts)

Yes, it does.  Without the delay measurement (and relying only on packet
loss for delay/congestion), the system/routers have to actually drop
packets before the terminal can determine that there is a problem.  The
service has to actually be degraded by packet losses before the system
can react which we consider "too late."

> 
> Something like ECN might be useful here; this is (sort of) an attempt
to
> do application-level ECN - and from a practical point of view, it may
be
> justified, though perhaps better ways of solving the problem can be
found.

Yes, this is like application level ECN. A solution with IP/RTP level
ECN may not work here as the wireless link scheduler does not operate at
IP level.

> >    Steve Casner commented that you don't really care about the delay
> when
> >    what you are changing is the rate. If the rate quickly varies,
then
> >    service will not be appealing due to frequently occurring rate
> >    changes.  Instead it is likely that the service will use the
lowest
> >    available rate and the adaptation will not need to happen. The
> quality
> >    if you adapt will be worse than if you run at the lowest rate
> >    constantly available.
> 
> Maybe, maybe not - but "lowest constantly available" is often not a
known
> or knowable value, and changes.   The value may be 0 - for short
periods,
> but be quite good the majority of the time.  That's a big difference
> between wireless (especially mobile) and typical internet fixed links.
> 
> >    Joerg Ott expressed concern that the use of AVPF events will not
> work
> >    well with this system: the feedback will be queued in the network
> and
> >    this delay will causing slow response and likely oscillation.
> 
> This is certainly an issue - though the wireless guys might be less
> worried about uplink, or have some way to give priority to AVPF
messages
> in
> the outbound queue.  But usually the upstream and downstream are
separate
> and so congestion in the downstream doesn't have to imply congestion
in
> the
> upstream.  In wireless, they're perhaps a bit more likely to be linked
> (due
> to RF quality), but it may not be a major problem - it would be
> interesting
> to model what happens in both-way congestion.

The draft prevents sending of a new PDAR feedback message until the last
one is ACK-ed, there is no way more than one feedback message can be
queued in the network.  So the oscillations due to queued feedback
messages would not happen.

Some wireless systems can attempt to reduce the feedback delay by
providing a higher priority flow for the RTCP traffic.
> 
> >    He also noted that AVPF is not intended for frequent reporting
and
> >    congestion control, but instead to report occasional media
events. AC
> >    responded that not using the feedback to prevent congestion would
> >    cause even greater congestion. This is true, but Joerg's point is
> that
> >    better congestion control can be achieved using a protocol
designed
> to
> >    provide congestion feedback, rather than trying to retrofit it
onto
> >    AVPF.
> 
> Which is a very good point - if there's a mechanism available for it.
> (ECN?)

RTCP Reports is the best place holder to report the receiver's
perception of the media in general. This is not the draft which started
recommending the use of reports for a different purpose other than the
ones mentioned by Joerg Ott. This draft has taken the concept (using the
RRs for codec control) introduced by another draft (CCM)
> 
> >    Colin Perkins summarised that the proposal got pretty strong
push-
> >    back.  Cullen Jennings commented that if this is to be chartered
> there
> >    would need to be people confident in stating -- with strong
evidence
> >    to show as justification -- that packet delay would work even if
we
> >    normally use packet loss to measure congestion.
> 
> I think it would, but more research may be needed.  Conceptually, most
> routers queue some amount (in total or per-stream) before dropping,
and
> then drop with one of several models (lots of research has been done
here).
> Wireless might be "unusual" here in that the queues might be much
deeper
> (can someone (AC?) verify this?)

In wireless networks, the queues for the forward link scheduler will
tend to be longer (in terms of time) because the scheduler will try to
take advantage of multi-user diversity to improve capacity. In the
wireless technologies we are considering, the additional objective of
maximizing cell throughput (which is maximized by scheduling the users
in the best link conditions more often) can require more queuing for a
user.

Thanks,
Hari

> 
> --
> Randell Jesup, Worldgate
> [email-masked]
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Tue, 25 Apr 2006 11:38:31 -0400

"Desineni, Harikishan" <[email-masked]> writes:
>> Also, current congestion control methods rely strongly on packet-drop as
>> an indirect signal of congestion.  That method is probably not
>> appropriate for a wireless situation (where packet-drop might be due to
>> channel loss, or congestion/channel-bandwidth).
>

So, if it's "well known and understood", what's the suggested solution?
RFC 3168 is all well and good, but from a cursory reading it appears that
until support for it is fairly widespread, it may not survive through
the network (and is of no use unless the routers that are congested support
it).  Also, there's no definition of how it would work for UDP, just
TCP and tunnels, etc.  Note also that RFC 3168 doesn't push routers to
signal until they're nearing the drop-point, which may be later than a
real-time application would want to know about it, especially wireless
or other routers that use deep queues to handle variable link conditions,
etc. 

Since we can't wave a wand and have ECN implemented, other solutions
are worth looking into.  ECN should be used when it's possible, I suspect.

>> Also, it's possible (and worth investigating) if channel-delay gives an
>> "early-warning" signal of problems in this case, before packets are
>> dropped.  (This depends on how aggressive the routers/channels are in
>> dropping versus queuing - a general-purpose wireless link might keep
>> deep queues to compensate for occasional dropouts)
>

Agreed - and even a deep queue without drop is a form of degradation
(delay).

>RRs for codec control) introduced by another draft (CCM)

RTCP does seem to me to be the place to indicate reception quality issues,
which this is.  What to communicate, under what conditions and how to
respond are other questions.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]