Re: [AVTCORE] WGLC on draft-ietf-avtcore-ecn-for-rtp-04

[Magnus Westerlund <[e-mail]>]

Hi,

Thanks for the comments.

On 2011-10-13 19:35, Dan Wing wrote:
> Two comments:
> 
> 1. The section
> http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2
> does not seem to discuss what happens if the ECN-marked ICE messages are
> discarded (e.g., by an aggressive firewall).  This seems to be an oversight.
> For this to work better, I suggest sending two STUN messages, back to back:
> one with ECN set and the other with ECN clear.  If the response to the
> ECN-set message isn't received within, say, 20% of the time for the
> ECN-cleared message, assume ECN-marked messages are being dropped/filtered.
> Note one of the non-ECN'd messages can be the normal ICE exchange, so if
> you're already doing ICE I am not proposing any additional messages on the
> wire.
> 
> I expect the other packet probes (RTP/RTCP probes) may need similar
> consideration / adjustment.

Yes, you are correct that we don't have a specification for when the ICE
client should consider the ECN check as being failed. I think we should
allow the ICE agent to send multiple transmissions of the ECN STUN check
packets. The second aspect is that I think 20% extra delay is to little.
The STUN packet may easily suffer that amount of network jitter.

My proposal would be to add the following paragraph to Section 7.2.2:

The ECN STUN checks may be lost on the path, either due to the ECT
marking in the ECN field or for some other reason. The first will result
in a failure to verify the path as ECT. The second should not result in
a failure to verify the path. Therefore a number of retransmissions
should be attempted. But, the sender of ECN STUN checks will also have
to set a criteria for when it gives up testing for ECN capability on the
path. As the ICE agent have successfully verified the path a RTT
measurement for this path can be performed. To have high probability of
succesfully verifying the path it is RECOMMENDED that the client
retransmitt the ECN STUN check 5 times. The interval between the
retransmissions will be based on the Ta timer as defined in Section 16.1
for RTP Media Streams in ICE [RFC5245]. The number of ECN STUN checks
needing to be sent will depend on the number of ECN capable flows (N)
that is to be established. Thus the interval between each transmission
of an ECN check packet MUST be Ta. In other words for a given flow being
verified for ECT the RTO is set to Ta*N. The transmission for that flow
is stopped when an ECN Check STUN response has been received which don't
indicate to retransmit the request due to temporary error. The ICE agent
is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms)
after the last ECN STUN check was sent.


When it comes to RTP I think we have a clear criteria for failure in 7.2.1:

ECN initiation is considered to have failed at the instant when any RTP
session participant sends an RTCP packet that doesn't contain an RTCP
ECN feedback report or ECN summary report, but has an RTCP RR with an
extended RTP sequence number field that indicates that it should have
received multiple (>3) ECT marked RTP packets. This can be due to
failure to support the ECN feedback format by the receiver or some
middlebox, or the loss of all ECT marked packets. Both indicate a lack
of ECN support.

> 
> 
> 2. The section
> http://tools.ietf.org/html/draft-ietf-avtcore-ecn-for-rtp-04#section-7.2.2
> can be summarized as:
> 
>   a. do normal ICE
>   b. use ICE messages to do an ECN validation
>   c. if (b) showed ECN worked, start sending RTP with ECN.  
>   d. if (b) showed ECN failed, start sending RTP without ECN.
> 
> Step (b-d) adds additional call setup time, which is undesirable.
> 
> Instead, I would prefer changing two aspects:  (1) not relying or caring
> about an initial ICE transaction (which means we can have both endpoints
> merely do ICE-Lite, if they wish -- we only need to know they will respond
> to ICE, really -- we don't need all of the other ICE overhead to use ICE to
> test the path is ECN capable), and (2) sending non-ECN'd RTP without
> waiting.  That can be summarized as:
> 
>   a. immediately start sending RTP without ECN
>   b. use ICE messages to do ECN validation
>   c. if (b) showed ECN worked, start sending RTP with ECN.  
>   d. if (b) showed ECN failed, start sending RTP without ECN.

I disagree with the disconnection from ICE processing. First of all the
side that want to determine if the path from it to the other side must
be an ICE node. The other side could be an ICE-Lite supporting the ECN
check attribute. But if the goal is to establish if the path is ECT
bi-directionally then both sides need to be ICE capable.

Secondly, I think the optimization you propose is good and I think we
can accept it with the note that I would like much more conservative ECN
STUN check transmission schedule if we are going to do media in parallel.

However, this is an substantiative change so I would like to see if
there is WG support for it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------