Skip to main content

Duplication Delay Attribute in the Session Description Protocol
RFC 7197

Yes

(Gonzalo Camarillo)
(Ted Lemon)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)

Note: This ballot was opened for revision 02 and is now closed.

(Gonzalo Camarillo; former steering group member) Yes

Yes (for -02)

                            

(Ted Lemon; former steering group member) Yes

Yes (for -02)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -02)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2013-11-15 for -02)
-- Section 3 --
Where does the new ABNF production, "delaying-attribute", fit into other ABNF?  Should this be extending an existing ABNF element to add "delaying-attribute" as a new possible value (from a formal ABNF point of view)?

Is a dupliation delay of 0 semantically valid?

(Benoît Claise; former steering group member) (was Discuss) No Objection

No Objection (2013-12-16)
thanks.

(Brian Haberman; former steering group member) No Objection

No Objection (for -02)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -02)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -02)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -02)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (2013-11-19 for -02)
Section 1:
"Furthermore, delayed duplication must not be used in cases where the primary cause of packet loss is congestion"
Like Benoit, I agree that this sentence is confusing.  Do you really mean something like the following?
"""
Delayed duplication (or duplication at all) is harmful in cases where the primary cause of packet loss is congestion, rather than network than a network outage due to a temporary link or network element failure.  Duplication should only be used by endpoints that want to protect against network failures; protection against congestion must be achieved through other means.
"""

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -02)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2013-12-06)
Thanks for handling my discuss. I think you need a 
reference for Lucky13 - see [1] where'll you'll find
that.

[1] http://www.isg.rhul.ac.uk/tls/Lucky13.html

---- old comments below, I didn't check them

- The ABNF allows for infinite numbers of delays and
infinitely large delays. Wouldn't it be better to limit
both?

- The fact that "a=duplication-delay: 50 100" means that
the 2nd re-tx is 150 ms after the initial tx is only
explained in the 2nd example and you never say that
otherwise. That could lead to interop problems since my
initial assumption would have been that the 2nd re-tx
would be 100ms after the initial tx for the above
example. I think you should say something about that in
section 3.

- What if the delay indicated is less than a packet, say
if every packet has 20ms of media but 5ms is indicated
in the SDP?

(Stewart Bryant; former steering group member) (was Discuss) No Objection

No Objection (2014-01-20)
Thank you for addressing my concern.

Within the new text, "Lucky13" does not have a reference and I think it needs one (or that second example in the sentence being removed).