Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt

From: "Ali C. Begen" <[email-masked]>
Date: Mon, 5 Oct 2015 12:48:37 +0300

Hi Thomas

the chances look good to me, but rather than saying "will be ignored",
you should probably say "SHALL be ignored".

-acbegen

On Thu, Oct 1, 2015 at 2:16 AM, Thomas Edwards <[email-masked]> wrote:
> I believe that Kevin Gross pointed out some important issues in
> draft-ietf-payload-rtp-ancillary-01, and I would like to ask the Payload WG
> to allow me to update the I-D to draft-ietf-rtp-ancillary-02.  A draft is
> attached.
>
> Also addition to some off-list comments:
>
> To "An ANC packet with the header fields Line_Number of 0x7FF and
> Horizontal_Offset of 0xFFF SHALL be considered to be carried without any
> specific location within the field or frame" add ", and in such a case the
> "C" field will be ignored."
>
> My replies to Kevin inline starting with "TE>".
>
> -Thomas Edwards
>  FOX
>
> From: Kevin Gross <[email-masked]>
> Date: Thursday, June 4, 2015 at 3:13 PM
> To: FNG <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-ancillary-01.txt
>
> Thomas,
>
> I have some additional comments on your draft:
>
>
> Abstract:
>
> Consider providing a definition for "KLV" early on
>
> TE> I will get rid of "KLV Metadata", as it is a very rare use case.
>
> 1 Introduction:
>
> Jargon attenuation
> s/carriage of metadata within the bit stream multiplex of a Serial Digital
> Interface/carriage of metadata within the bit stream of a Serial Digital
> Interface
>
> Payload does not describe
> s/This RTP payload supports ANC data packets/This memo describes an RTP
> payload which supports ANC data packets
>
> Quotes unnecessary
> s/restored to their "original" locations/restored to their original
> locations
>
> Other wording improvements
> s/This payload could be used by itself, or used along with a range of RTP
> video formats. In particular, it has been specifically designed so that it
> could be used/This ANC payload can be used by itself, or used along with a
> range of RTP video formats. In particular, it has been designed so that it
> could be used
>
> TE> Wording improvements accepted
>
> 2.1 Payload Header Definitions
>
> Is there a justification you can provide for including Extended Header
> Sequence Number. Video payload protocols potentially require this because
> there may be many packets per video frame. I don't think that's the case for
> ANC. What is the maximum realistic rate for ANC data?
>
> TE> It depends on what type of ANC data is mapped.  There could easily be
> several hundred ANC packets per frame if embedded audio is carried in RTP.
> There can be as much as 563 Mbps of ANC space in 720p50 HD-SDI.  I have had
> many inconclusive discussions with experts on this, and my intuition is that
> too many bits is better than too few bits when it comes to potential
> sequence number over-run, so I would prefer to leave the extended sequence
> number in.
>
> We need some additional information about the ANC format to complete this
> draft. How do we find the beginning of each ANC packet in the payload? Where
> in an ANC packet is the Ancillary Data Flag (ADF)?
>
> TE> The Ancillary Data Flag is not present in the payload because it is a
> property of an SDI interface involved, and has no bearing on the ANC packet
> data.  In all digital component interfaces I am aware of it is 000h 3FFh
> 3FFh.  I will add "It should be noted that the ancillary data flag (ADF)
> word is not specifically carried in this RTP payload.  The ADF may be
> specified in a document defining an interconnecting digital video interface,
> otherwise a default ADF is specified by SMPTE ST 292-1 [ST292]."
>
> Where do DID values come from?
>
> TE> "The fields DID, SDID, Data_Count, User_Data_Words, and Checksum_Word
> represent the 10-bit words carried in the ANC data packet, as per SMPTE ST
> 291"
>
> Based on what I've cleaned from the draft, it seems that we don't need both
> Length and ANC_Count. It seems like either would be sufficient to determine
> where payload data stops. You could possibly do without either and use the
> Length field in the UDP header to know when data ends.
>
> TE> I prefer the RTP ANC payload parser to know how large the ANC data
> packet payload is without having to refer to higher level network
> information.  Hopefully that is not an RTP anti-pattern.  ANC_Count does not
> directly tell you a size, only the number of ANC packets present, which
> would have to be iterated through as ANC packets may have different lengths.
>
> It is not clear to me what happens at (next ANC data packet). Is there
> another DID here or do we get a new Line_Number or something else? We need a
> better description of what an ANC data packet is.
>
> TE> I thought I was being clear with the statement "And for each ANC data
> packet in the payload, the following header fields MUST be present:" but
> indeed I am less clear regarding DID,SDID,etc.  I will add "For each ANC
> data packet in the payload, immediately after the ANC data packet header
> fields, the following  data fields MUST be present, with the fields DID,
> SDID, Data_Count, User_Data_Words, and Checksum_Word representing the 10-bit
> words carried in the ANC data packet, as per SMPTE ST 291-1:"
>
> There's something off in Checksum_Word description, "The lower 8 bits of
> Checksum_Word, corresponding to bits b8 (MSB) through b0 (LSB) of the 10-bit
> data count word". b8 through b0 is 9 bits.
>
> TE> Agreed.  I will replace with description "It consists of 10 bits, where
> bits b8 (MSB) through b0 (LSB) define the checksum value and bit b9 is the
> inverse (logical NOT) of bit b8."
>
>
> Kevin Gross - AVA Networks
>
> On Wed, Jun 3, 2015 at 6:50 PM, Thomas Edwards <[email-masked]>
> wrote:
>>
>> Based on input from SMPTE members, the following changes were made in the
>> new draft-ietf-payload-rtp-ancillary:
>>
>> 1) Made this explicitly clear:
>>
>> "If more than 255 ANC data packets need to be carried in a field or frame,
>> additional RTP packets carrying ANC data may be sent with the same RTP
>> timestamp but with different sequence numbers."
>>
>> 2) Added a "don't care" value of 0xFFF to Horizontal_Offset to indicate if
>> the ANC data is carried without any specific location within the line.
>>
>> 3) Made this explicitly clear:
>>
>> "An ANC packet with the header fields Line_Number of 0x7FF and
>> Horizontal_Offset of 0xFFF SHALL be considered to be carried without any
>> specific location within the field or frame."
>>
>> 4) Made this explicitly clear:
>>
>> "When reconstructing an SDI signal based on this payload, it is
>> important to place ANC packets into the locations indicated by the    ANC
>> payload header fields Line_Number and Horizontal_Offset, and also    to
>> follow the requirements of SMPTE ST 291-1 [ST291] Section 7    "Ancillary
>> Data Space Formatting (Component or Composite Interface)",    which
>> include rules on the placement of initial ANC data into allowed    spaces
>> as well as the contiguity of ANC data packet sequences within    those
>> spaces in order to assure that the resulting ANC packets in the    SDI
>> signal are valid."
>>
>> 5) A more clear example of multiple DID_SDID parameters in SDP.
>>
>> 6) Minor editorial nits.
>>
>> If there is any concern with these changes, please let me know!
>>
>> -Thomas
>>
>> --
>> Thomas Edwards
>> VP Engineering & Development
>> FOX Networks Engineering and Operations
>> [email-masked]
>> Phone: +1.310.369.6696
>> 10201 West Pico Blvd.
>> Los Angeles, CA 90035
>>
>> _______________________________________________
>> payload mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/payload
>
>
>
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Kevin Gross <[email-masked]>
Date: Thu, 8 Oct 2015 12:26:37 -0600

Thanks Thomas. Proposed resolutions look acceptable to me.

On Wed, Sep 30, 2015 at 5:16 PM, Thomas Edwards <[email-masked]>
wrote:

> I believe that Kevin Gross pointed out some important issues
> in draft-ietf-payload-rtp-ancillary-01, and I would like to ask the Payload
> WG to allow me to update the I-D to draft-ietf-rtp-ancillary-02.  A draft
> is attached.
>
> specific location within the field or frame" add *", and in such a case
> the "C" field will be ignored."*
>
> *TE> I will get rid of "KLV Metadata", as it is a very rare use case.*
>
> 1 Introduction:
>
> Jargon attenuation
> s/carriage of metadata within the bit stream multiplex of a Serial
> Digital Interface/carriage of metadata within the bit stream of a Serial
> Digital Interface
>
> video formats. In particular, it has been specifically designed so that
> it could be used/This ANC payload can be used by itself, or used along
> with a range of RTP video formats. In particular, it has been designed so
> that it could be used
>
> *TE> Wording improvements accepted*
>
> there may be many packets per video frame. I don't think that's the case
> for ANC. What is the maximum realistic rate for ANC data?
>
> *TE> It depends on what type of ANC data is mapped.  There could easily be
> many inconclusive discussions with experts on this, and my intuition is
> that too many bits is better than too few bits when it comes to potential
> number in.*
> draft. How do we find the beginning of each ANC packet in the payload?
> Where in an ANC packet is the Ancillary Data Flag (ADF)?
>
> *TE> The Ancillary Data Flag is not present in the payload because it is a
> specified in a document defining an interconnecting digital video
> interface, otherwise a default ADF is specified by SMPTE ST 292-1 [ST292]."*
>
> *TE> "The fields DID, SDID, Data_Count, User_Data_Words, and Checksum_Word
> 291"*
> Based on what I've cleaned from the draft, it seems that we don't need
> both Length and ANC_Count. It seems like either would be sufficient to
> determine where payload data stops. You could possibly do without either
> and use the Length field in the UDP header to know when data ends.
>
> *TE> I prefer the RTP ANC payload parser to know how large the ANC data
> information.  Hopefully that is not an RTP anti-pattern.  ANC_Count does
> not directly tell you a size, only the number of ANC packets present, which
> would have to be iterated through as ANC packets may have different
> lengths.*
>
> another DID here or do we get a new Line_Number or something else? We need
> a better description of what an ANC data packet is.
>
> *TE> I thought I was being clear with the statement "And for each ANC data
> indeed I am less clear regarding DID,SDID,etc.  I will add "**For each
> ANC data packet in the payload, **immediately after the ANC data packet
> header fields, **the following  data fields **MUST be present, with the
> fields DID, SDID, Data_Count, **User_Data_Words, and Checksum_Word
> representing the 10-bit words **carried in the ANC data packet, as per
> SMPTE ST 291-1:"*
>
> Checksum_Word, corresponding to bits b8 (MSB) through b0 (LSB) of the
> 10-bit data count word". b8 through b0 is 9 bits.
>
> *TE> Agreed.  I will replace with description "It consists of 10 bits,
> where bits b8 (MSB) through b0 (LSB) define the checksum value and bit b9
> is the inverse (logical NOT) of bit b8." *
>
>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=AwMFaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=_iK-42BnvmbbP5Nr7_ClbyieBpuYdQPuRKOiVC2SpSE&s=88mmYChaLERR_FxxOM64DpHnl6PPDZigq3GASMJHVpw&e=>
>>
>
>

---

From: Thomas Edwards <[email-masked]>
Date: Mon, 19 Oct 2015 21:40:12 +0000

Regarding draft-ietf-payload-rtp-ancillary-01, I will change "will be
ignored" to "SHALL be ignored" regarding ANC packets to be carried without
any
specific location within the field or frame as Ali suggests, and will
update to draft-ietf-payload-rtp-ancillary-02 (given the cut-off deadline
for IETF94 today).

I also received an off-list comment regarding the marker bit.
Implementers of the I-D have told me that it is often difficult to know
which ANC packet is truly the "last one" in the frame due to their
sparseness.  To truly use the marker bit to indicate the last ANC packet
of a frame would mean a very long latency between the time an ANC packet
comes in and the time the frame comes to an end.

To mitigate this, the off-list commenter suggested that they would prefer
the marker bit to indicate the first RTP packet of a frame, rather than
the last.  Other solutions include not using a marker bit for this data
type, or requiring an empty RTP packet at the end of the frame with the
market bit set, however the commenter did not prefer those solutions.
 
I recognize that using the marker bit to indicate the first ANC packet in
a frame is a bit unusual for RTP, but I believe that it is the best
solution to the problem.

If there is no objection, I could move forward with this marker bit
definition and update to draft-ietf-payload-rtp-ancillary-03, a draft of
which is attached.

-Thomas

On 10/5/15, 2:48 AM, "Ali C. Begen" <[email-masked]> wrote:

>>Digital
>>it
>>that
>>Where
>>interface,
>>both
>>lengths.
>>10-bit
>>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
>>>n_listinfo_payload&d=BQIBaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-E
>>>I&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=-iAfjzMHWUFUJ75wLZ6BbA
>>>JMCDbZCAol_GFLrIMW0Ms&s=sZRCBbfY7k2eTlyjr78YZv4nsTxCNTtBcyFFlSAlnck&e=
>>
>>
>>
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman
>>_listinfo_payload&d=BQIBaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&
>>r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=-iAfjzMHWUFUJ75wLZ6BbAJMC
>>DbZCAol_GFLrIMW0Ms&s=sZRCBbfY7k2eTlyjr78YZv4nsTxCNTtBcyFFlSAlnck&e=
>>

---

From: "Ali C. Begen" <[email-masked]>
Date: Wed, 21 Oct 2015 13:08:20 +0300

Hi Thomas

I agree with using the market bit to indicate the first ANC packet in
a frame. As long as the payload definition is clear, I dont see a
problem with that.

-acbegen