Subject: [AVT] Two questions on "ECN for RTP"

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 13 Aug 2009 17:37:21 +0200

Hi,

I have some questions with respect to the proposals made to allow ECN to
work also for RTP/UDP, more in particular the draft
http://www.ietf.org/id/draft-westerlund-avt-ecn-for-rtp-00.txt . I
support this proposal in general, but the 2 questions I have, are:

-why does the draft propose to report WHICH  packets were received with
ECN-CE value(s), part of the feedback interval in the newly defined ECN
feedback RTCP FB message . To what extent is this relevant for the
congestion response (e.g. rate adaptation)  by the server?
-this same proposed message also includes indication on whether packet
loss was detected and again a bitmap allowing to report which packets
were lost. Same comments as per above and furthermore this information
also has 100% overlap with the RTCP NACK FB message of RFC 4585.

Thanks for any clarification
Tom

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Aug 2009 22:06:49 +0100

On 13 Aug 2009, at 16:37, VAN CAENEGEM Tom wrote:
> I have some questions with respect to the proposals made to allow  
> ECN to work also for RTP/UDP, more in particular the draft http://www.ietf.org/id/draft-westerlund-avt-ecn-for-rtp-00.txt 
>  . I  support this proposal in general, but the 2 questions I have,  
> are:
>
> -why does the draft propose to report WHICH  packets were received  
> with ECN-CE value(s), part of the feedback interval in the newly  
> defined ECN feedback RTCP FB message . To what extent is this  
> relevant for the congestion response (e.g. rate adaptation)  by the  
> server?
>
> -this same proposed message also includes indication on whether  
> packet loss was detected and again a bitmap allowing to report which  
> packets were lost.
>

The feedback on which packets were lost and/or ECN marked was done to  
allow the sender to detect cheating receivers or middleboxes that re- 
write (zero-out) the ECN marks in transit. One of the open questions  
is whether that mechanism is the right way to detect these issues.

> Same comments as per above and furthermore this information also has  
> 100% overlap with the RTCP NACK FB message of RFC 4585.
>

True. We should likely re-use that message.

-- 
Colin Perkins
http://csperkins.org/

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 18 Aug 2009 16:10:42 +0200

Colin,

Thanks for responding and clarifying. However, I thought that the nonce
value was used by the sender to detect any fraud taking place by a
receiver and/or by a middle box along the path. I do not see how
identification of which packets that were ECN marked or lost, helps the
sender in this process. E.g. if the sender gets a RTCP FB message with a
bitmap indicating  packet N  up to packet N+5 were ECN-CE marked, how
would that be different from getting a message indicating packets M up
to M+5 were ECN-CE marked?  
IMO, all that matters is the number of packets reported as lost/ECN-CE
marked in the reported SN space?     

Tom

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: maandag 17 augustus 2009 23:07
To: VAN CAENEGEM Tom
Cc: [email-masked]
Subject: Re: [AVT] Two questions on "ECN for RTP"

On 13 Aug 2009, at 16:37, VAN CAENEGEM Tom wrote:
> I have some questions with respect to the proposals made to allow ECN 
> to work also for RTP/UDP, more in particular the draft 
> http://www.ietf.org/id/draft-westerlund-avt-ecn-for-rtp-00.txt
> defined ECN feedback RTCP FB message . To what extent is this relevant

> for the congestion response (e.g. rate adaptation)  by the server?
>

> were lost.

The feedback on which packets were lost and/or ECN marked was done to
allow the sender to detect cheating receivers or middleboxes that re-
write (zero-out) the ECN marks in transit. One of the open questions is
whether that mechanism is the right way to detect these issues.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 18 Aug 2009 15:28:21 +0100

Tom,

You might have a different congestion response, depending on which  
packets were lost/marked. For example, if tightly spaced packets are  
marked, this might be considered a single congestion event, where as  
the same fraction of packets being marked over a longer period of time  
might be treated as several loss events. We want to allow flexibility  
in the congestion response, since it's not clear what's the correct  
response.

Colin

On 18 Aug 2009, at 15:10, VAN CAENEGEM Tom wrote:
>> relevant
>> packet
> is
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/