Skip to main content

Duplication Delay Attribute in the Session Description Protocol
draft-ietf-mmusic-delayed-duplication-03

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 IESG member
Yes
Yes (for -02) Unknown

                            
Ted Lemon Former IESG member
Yes
Yes (for -02) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-11-15 for -02) Unknown
-- 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 IESG member
(was Discuss) No Objection
No Objection (2013-12-16) Unknown
thanks.
Brian Haberman Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (2013-11-19 for -02) Unknown
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 IESG member
No Objection
No Objection (for -02) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-12-06) Unknown
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 IESG member
(was Discuss) No Objection
No Objection (2014-01-20) Unknown
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).