Re: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

[Christer Holmberg <[e-mail]>]

Hi Gunnar,

>>>>> 4. In 3, delete "using the RTP timestamp". It is usually the sequence number that helps finding where data is missing.
>>>> The sequence number is used to detect missing data, but the timestamp is used for data redundancy.
>>>>
>>>>     "The RTP header is followed by one or more redundant data block
>>>>     headers: one for each redundant data block to be included.  Each of
>>>>     these headers provides the timestamp offset and length of the
>>>>     corresponding data block,"  (RFC 4103, Section 4.1)
>>>
>>> {GH] Well, that is the coding of the redundancy data block, but not how
>>> loss is detected.
>>
>> The beginning of the sentence says:
>>
>>     "Instead, when RTP based transport is used, the RTP sequence number is used
>>      to detect packet loss and out-of-order packets"
>>
>>> I do not know any implementation that bothers about
>>> details in the RTP timestamp for detecting loss.
>>
>>      The text doesn't say that :)
>
> [GH] But it also does not say how you can use the timestamp to detect loss and recover data from redundancy.

It says that you can use the sequence number to detect loss.

> RFC 4103 is using the redundancy mechanism in RFC 2198 originally used for audio redundancy. Maybe the
> timestamp is of more value there, when playing out audio is more time-critical than real-time text. The text 
> you cited in RFC 4103 only tells how to code the redundancy block, not how to use the info for recovery. 
> What we have in the t.140 data channel draft is sufficient without mentioning the timestamp in RFC 4103. 
> Can we delete the discussed phrase?

I was asked to add a note that describes why we are using reliable and in-ordered transmission on the data channel, and why we can't use the
loss detection and redundancy encoding mechanisms defined for RTP in RFC 4103.

Also, the note does not talk about how redundancy blocks are encoded, it only says that there is a redundancy mechanism based on the usage of the RTP timestamp.

But, if you don't want to talk about the "RTP timestamp", perhaps we could talk about "redundancy being provided using a mechanism based on duplicating T140blocks".

...


>>>>> 13. In 6. Gateway considerations:
>>>>> At the end of bullet point 4 add "in reception"
>>>> I think "was lost in reception" sounds strange.  What about "was lost due to the data channel failure"?
>>> [GH] I wanted to point out in what direction it was lost. In T.140 data
>>> channels, the sender has in fact better opportunity than the receiver to
>>> detect if something was lost. Bullet point 4 was intended to tell about
>>> data received on the T.140 data channel to be sent on the RTP stream. I
>>> want to insert a new bullet point (see 14) for when the gateway detects
>>> loss in sending in the T.140 data channel. Therefore it should be clear
>>> that bullet point 4 is for the reception case. What about "was lost when
>>> receiving from the T.140 data channel due to the data channel failure" ?
>>      
>>      What about?
>>
>>      "that data sent by the T.140 data channel endpoint has been lost."
>
> [GH] I do not see why you do not like to mention reception here, so that it is clear in which direction there may have been a loss.

I think talking about reception of something that was loss sounds strange. It is was lost, it wasn't received.

>But your proposal may perhaps work if we clearly indicate the roles by inserting "remote" like this:
>
>     "that data sent by the remote T.140 data channel endpoint has been lost."
>
> because the gateway is also a kind of endpoint.

I agree. We can do that.

Regards,

Christer



>
> Regards,
>
> Christer
>
>
>
>
>      > Den 2019-10-02 kl. 15:25, skrev Bo Burman:
>      > Greetings MMUSIC ,
>      >
>      > This is to announce a 2 week WGLC on the draft:
>      >
>      >      https://protect2.fireeye.com/url?k=806502d9-dcecd8e4-80654242-0cc47ad93c0c-e10d1004cdda139e&q=1&u=https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt
>      >
>      > as Proposed Standard. Please review and provide any comments you may have on the document by Wednesday, October 16, 2019. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.
>      >
>      > Thanks,
>      >
>      > /Bo
>      > (MMUSIC co-chair)
>      >
>      >
>      >
>      > _______________________________________________
>      > mmusic mailing list
>      > mailto:[e-mail]
>      > https://protect2.fireeye.com/url?k=a6662b9d-faeff1a0-a6666b06-0cc47ad93c0c-f61b6b0757d55756&q=1&u=https://www.ietf.org/mailman/listinfo/mmusic
>      >
>      --
>      
>      + + + + + + + + + + + + + +
>      
>      Gunnar Hellström
>      Omnitor
>      [e-mail]
>      [phone]
>      
>      
>
-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[e-mail]
[phone]