Subject: Re: [payload] Mirja Kühlewind's No Objection on draft-ietf-payload-rtp-ancillary-10: (with COMMENT)

From: Thomas Edwards <[email-masked]>
Date: Thu, 21 Sep 2017 15:32:48 +0000

Mirja,

Thanks for your comment.  This section was a consensus decision added after some significant discussion about the requirements for timeliness of emission of RTP packets of ANC data, thus I believe it needs to stay in the document.  The time a conversion device between SDI and RTP waits between reception of an ANC data packet and RTP transmission of that ANC data packet is time that needs to be replicated in a buffer on a receiving device that would re-create the SDI output, implying both larger buffers and higher overall latency (as the output video would need to be retarded to match the line the ANC data packet is to be inserted on).

I doubt a practical professional media networking system would be built around a 1ms delay NIC, as fairly simple implementations of 10 GbE networks can show round-trip times of tens of microseconds (see: https://blog.cloudflare.com/how-to-achieve-low-latency/)  Many early devices would be built around FGPAs or kernel bypass (e.g. DPDK).

-Thomas 

-- 
Thomas Edwards
FOX Networks Engineering & Operations
VP Engineering & Development
[email-masked]
+1-310-369-6696
10201 W Pico Blvd
Los Angeles, CA 90035

On 8/15/17, 1:58 AM, "payload on behalf of Mirja Kühlewind" <[email-masked] on behalf of [email-masked]> wrote:

    Mirja Kühlewind has entered the following ballot position for
    draft-ietf-payload-rtp-ancillary-10: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)

    Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=1CItcAlVuxV0NArf_oJbJQ6SZVQB6t5FCuoNVUejgtc&s=mRfoNB2iwg__4K05WyniLeLNYlbZxXkf5MwFz3RQtYY&e= 
    for more information about IESG DISCUSS and COMMENT positions.

    The document, along with other ballot positions, can be found here:
    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dpayload-2Drtp-2Dancillary_&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=1CItcAlVuxV0NArf_oJbJQ6SZVQB6t5FCuoNVUejgtc&s=WeDF84yJWiWE8rB1oK_kLl9Q5TGevMhwCxjO6UjyTPk&e= 

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    One comment at the end of section 2:
    "One millisecond is a reasonable upper bound for the
       amount of time between when an ANC data packet becomes available to a
       sender and the emission of an RTP payload containing that ANC data
       packet."
    While it makes sense to send out the packet as soon as possible, I'm not sure
    what this sentence gives you. I don't think you can guanrantee 1ms as there
    might be additional delays on the NIC and as such I don't think there are any
    actions that could follow based on this value. To avoid that anybody is taking
    this as a hard requirement, I would maybe rather just remove this note.

    _______________________________________________
    payload mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwIGaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=1CItcAlVuxV0NArf_oJbJQ6SZVQB6t5FCuoNVUejgtc&s=Um0Tdvi5qC0ZZPcsrmNJjcG463d-EmOhyohSXUhBrAk&e=