[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Comments on draft-ietf-avt-rfc2793bis-08
Magnus,
1. I accept that we should put in the words "any used profile, e.g. " as you propose in
section 9.
2. I suggest that we change the sentence "As guidance, some load figures are provided
here." to read: "As guidance, some load figures are provided here as examples based on use
of IPv4, including the load from IP, UDP and RTP headers without compression." And the
words "no header compression" deleted form a paragraph further down. That would clarify
the background to the load examples better.
Thanks,
Gunnar
-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
Gunnar.Hellstrom at Omnitor.se
--------------------------------------------
>-----Original Message-----
>From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com]
>Sent: Thursday, July 22, 2004 9:46 AM
>To: Gunnar Hellstrom
>Cc: IETF AVT WG; Paul E. Jones
>Subject: Re: [AVT] Comments on draft-ietf-avt-rfc2793bis-08
>
>
>Hi Gunnar,
>
>Response inline:
>
>Gunnar Hellstrom wrote:
>
>>>1. I think there are a few places where the draft is implicitly breaking
>>>the restriction of text/RED. When having defined a PT it implies a
>>>certain number of levels of redundancy. However the draft does not seem
>>>to keep to this. Examples where it is unclear are:
>>>- Section 5.3, last paragraph on page 11.
>>>- Second paragraph in Section 7.2
>>
>>
>> There are two explanations to this virtual discrepancy from what text/red says about
>> specifying levels of redundancy by sdp.
>> 1. Occationally there is no data to transmit. That may be seen as a temporary shift in
>> level of redundancy but I think it is just the nature of redundant repetition.
>When there
>> was no primary data to repeat, no redundant info can be included. That explains section
>> 7.2, and why this topic is brought up in section 5.3.
>
>Yes, I agree that this is a natural limitation, especially in audio,
>where the TS recovery is the prime thing. And I think the right place to
>address this issue is in a update of RFC 2198.
>
>> 2. I got the impression from the previous disussion about specification of the level of
>> redundancy that it rather was an accepted limitation when you use sdp to
>specify the level
>> that it should be fixed and signaled with the PT.
>> For other ways to specify the media, that restriction may not apply, and the possible
>> variations in levels implied by the rule in section 5.3 may be valid.
>> I would prefer not to change the text to explain that, but expect designers
>working under
>> the restrictions of sdp to keep to these restrictions. The rule in 5.3 about
>how to figure
>> out the level of redundancy may be used anyway as a complement to sdp parsing.
>>
>
>Yes, the rule in 5.3 is probably sufficient to get things right. In
>regards to SDP, I would say it is unclear if this restriction applies or
>not.
>
>
>>
>>>2. Section 9.
>>> "The congestion considerations from section 10 of RFC 3550 [2],
>>> section 6 of RFC 2198 [3] and the section about congestion in
>>> chapter 2 of RFC 3551 [11] apply with the following application
>>> specific considerations."
>>>
>>>I would like to change this sentence to be applicable for any profile:
>>>
>>> The congestion considerations from section 10 of RFC 3550 [2],
>>> section 6 of RFC 2198 [3] and any used profile, e.g. the section
>>> about congestion in chapter 2 of RFC 3551 [11], apply with the
>>> following application specific considerations.
>>
>> In 7.3 we already have this:
>> Note - While these examples utilize the RTP/AVP profile, it is not intended to
>limit the
>> scope of this memo to use with only that profile. Rather, any appropriate
>profile may be
>> used in conjunction with this memo.
>>
>> Do you still think we need to emphasise that statement according to your proposal?
>
>Yes, because they have different purposes. The statement in 7.3 says:
>this is only an example, any profile can be used.
>
>In section 9, we are talking about congestion control. It is an
>different point than the one in 7.3 that you also need to look in the
>profiles congestion control section.
>
>
>
>>
>>>3. Section 9:
>>> -With the (unusually high) load of 20 characters per second, in a
>>> language that make use of three octets UTF-8 characters, no header
>>> compression, two redundant levels and 300 ms between transmissions,
>>> the maximum load of this application is 3300 bits/s.
>>>
>>> -When the restrictions mentioned above are applied, limiting
>>> transmission to 10 characters per second, using 5 s between
>>> transmissions, the maximum load of this application in a language
>>> that uses one octet per UTF-8 character is 300 bits/s.
>>>
>>>Could you please clarify what is included in the bit-rate calculations.
>>>Currently I don't know if they include more than RTP header or not.
>>
>>
>> It is:
>> IP v4 IP and UDP headers, RTP header, redundancy headers, payload.
>>
>> I think that is a normal set when talking about network load.
>>
>> In reality we also might have Ethernet headers, or be in IPv6 environment.
>>
>> I think I should not include lower level headers ( like Ethernet ), But I might need to
>> check how much IP v6 would change. Minor, I guess.
>>
>>
>
>I agree that below IP should not be included in this type of
>applications. You should however explicitly declare what protocol
>assumptions you used in the calculation. Otherwise it is hard to
>determine if it is applicable for ones use case. And is the only change
>that I do request you to do.
>
>
>Cheers
>
>Magnus Westerlund
>
>Multimedia Technologies, Ericsson Research EAB/TVA/A
>----------------------------------------------------------------------
>Ericsson AB | Phone +46 8 4048287
>Torshamsgatan 23 | Fax +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
>
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt