Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 7 Persistent Errors

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2011 18:13:51 +0100

Hi,

This is a continuation of the issue 15A from the 08 review.

The issue is when a client should consider an error to be persistent, or
at least not short time temporarily or resolvable. If a client continues
to get Mapping responses with errors after having tried several times.
Maybe it should do exponential back-off. Maybe it should update its
session description. Similar for Verification Requests.

Some recommendation about such behavior I think has clear benefit and
reduced uncertainty in behavior by clients.

This was my last issue I have found in this review. A clear improvement
from the previous review of the document.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 14 Jan 2011 10:34:55 -0800

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, January 14, 2011 6:14 PM
> To: IETF AVT WG; [email-masked]
> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 7 Persistent Errors
> 
> Hi,
> 

This sounds like a good suggestion. How about adding the following to the end of section 6:

If a client receives a Port Mapping Response message with an invalid Token (i.e., the relative expiration time is set to zero) two or more times for a particular Port Mapping Request message, or the client receives a Token Verification Failure message two or more times for the same Token Verification Request message, the client SHOULD do the following:
1- Check whether the session description has been updated or not. If it was updated, act according to the new session description.
2- Exponentially back-off for the third and subsequent attempts.

Exponential back-off does not apply when the client sends a Port Mapping Request or Token Verification Request message to a new address and/or port.

Let me know if this text is good or you wanna modify it.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Jan 2011 11:19:47 +0100

> Let me know if this text is good or you wanna modify it.

Good enough I think.

Cheers

Magnus Westerlund