Re: [rtcweb] Comments on draft-ietf-rtcweb-transports-02

[Magnus Westerlund <[e-mail]>]

Please see inline.


On 2014-03-30 22:46, Harald Alvestrand wrote:
> Reviving an old thread, since I'm getting the changes in:
> 
> On 02/25/2014 11:46 AM, Magnus Westerlund wrote:
>> On 2014-02-19 19:47, Harald Alvestrand wrote:
>>> On 02/19/2014 11:08 AM, Magnus Westerlund wrote:

>>>> 2. Section 3.1:
>>>>    For both protocols, IPv4 and IPv6 support is assumed; applications
>>>>    MUST be able to utilize both IPv4 and IPv6 where available.
>>>>
>>>> What "applications" are intended in this sentence. I get a feeling that
>>>> "applications" here could be replaced by "WebRTC implementations"
>>> Javascript applications. I think I should add the word "application" to
>>> -overview's vocabulary; it is actually used in that meaning in that
>>> document (also in the forms "Web application" and "browser-based
>>> application".
>> Sorry, then I find the above requirement a bit strangely targeted. I
>> think we can require that IPv4 and IPv6 support for the applicable
>> protocol pieces in what we define. But, on the JS application level?
>> Also what explicit addressing information is visible on that level.
> 
> If two JS applications want to communicate, and the two systems are
> connected with IPv4 but not connected with IPv6, communication should
> happen, otherwise the implementation is non-conformant.
> 
> If the two systems are connected with IPv6 and not IPv4, communication
> should happen, otherwise the implementation is non-conformant.
> 
> Communication, or the lack of it, is clearly a property that's
> observable at the JS application level.
> 
> (the detail that the IPv* addresses are visible in the candidates and in
> the SDP is an implementation detail that doesn't belong here.)

I am not disagreeing with what you write above. However, the
implementation requirement on supporting IPv6 and IPv4 is on the WebRTC
endpoint, i.e. the media framework, the ICE implementation etc. A JS
application should be IP version agnostic as long as it doesn't much SDP
details.

That is why I raised this issue about "application" rather than the
WebRTC endpoint being the one that should support both IPv4 if endpoint
is provisioned with them.

> 
>>
>> It might be that this requirement needs to be split or at least apply to
>> multiple levels.
> 
> Or maybe rewritten to a language that we both understand. Leaving it
> roughly as-is for the moment.

Yes, rewrite is likely good.

> 
>>
>>>>
>>>> 3. Section 3.1:
>>>>    For UDP, this specification assumes the ability to set the DSCP code
>>>>    point of the sockets opened on a per-packet basis, in order to
>>>>    achieve the prioritizations described in
>>>>    [I-D.dhesikan-tsvwg-rtcweb-qos] when multiple media types are
>>>>    multiplexed.  It does not assume that the DSCP codepoints will be
>>>>    honored, and does assume that they may be zeroed or changed, since
>>>>    this is a local configuration issue.
>>>>
>>>> I wonder if this should be moved into 3.2 section instead. At least the
>>>> part in 3.1 should focus on the DSCP setting part on the transport flow.
>>>> The implications of it working or not should be moved to 3.2. A forward
>>>> pointer to that second can be used instead.
>>> I think it fits better in 3.1 - this is about the assumptions that the
>>> specifcation makes about the parts of the system that it is not a
>>> specification for.
>> I am fine with the first sentence staying, it is the second part that
>> needs more discussion and I think it should be moved and expanded on.
>> Thus a forward pointer may be appropriate here.
> 
> Added forward pointer, since I now have somewhere for it to point.

Good


>>>> 5. Content of Section 3.2
>>>>
>>>> This section needs to be expanded to start with a general discussion of
>>>> how QoS can be applied to get a benefit. But, I think one need to be
>>>> clear that it can't be assumed to be available in implementations or
>>>> WebRTC based applications.
>>> I want to push back on this. It seems inappropriate that the RTCWEB QoS
>>> specification start off with a tutorial on what QoS is and how one can
>>> use it to gain a benefit. That material should be available elsewhere.
>>> (Recommendations?)
>> I would like to agree with you, however we are putting together the
>> pieces in a way that stands some of the previous assumptions on their
>> heads. Thus, we don't have easy access to pointers.
>>
>> I can see this discussion going into
>> draft-ietf-avtcore-multiplex-guidelines when it concerns RTP. However,
>> you also have the data channel to consider. Thus, there exist no
>> references that I know that discusses this particular combination and
>> its implications.
>>
>>>> It needs to also discuss flow-based QoS mechanism. What are the
>>>> implications if that is what is available and what choices does one have
>>>> to address this by configuring the multiplexing different.
>>> I do not want to discuss material for which there are no references.
>>> What particular flow-based mechanisms do you have in mind, and what are
>>> the relevant references?
>> RSVP we can start with, but I think equally applicable is 3GPP QoS. But
>> finding the right reference here might be a bit problematic.
>>
>> I think one can cover the general property of flow based QoS in a single
>> sentence. However, that usage has implications for the peer connection
>> and its configuration. We have text in the rtp-usage that makes it clear
>> about the requirement to be able to send multiple RTP sessions on
>> different flows. But the combination with the data channel is not
>> covered. Thus, I think that belongs in the transports document. The
>> question is how much lead in material you need for that discussion?
> 
> I'll add some general words about 5-tuples and 6-tuples to the QoS section.
> Let's see if that resolves the remaining issues below; I don't want to
> use too much time on this before launching a revised document to invite
> others' comments.

Okay, I am fine with doing this incremental so that we can figure out
the appropriate boundaries and bring other docs up to required level also.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------