Re: [rmcat] comments RMCAT app interactions draft

[Karen Elisabeth Egede Nielsen <[e-mail]>]

Hi Mo, all



Please find follow up below.



BR, Karen



*From:* Mo Zanaty (mzanaty) [mailto:[e-mail]]
*Sent:* 22. oktober 2014 09:01
*To:* Karen Elisabeth Egede Nielsen
*Cc:* Mirja Kühlewind; Eggert, Lars;
[e-mail]
*Subject:* Re: comments RMCAT app interactions draft



Hi Karen,



Thank you for the comments. Adding co-authors to review my responses (see
Mo: inline) and provide their own as well. Feel free to include the list as
well if you think the discussion should be wider.



Best regards,

Mo



On 10/21/14, 12:06 PM, Karen Elisabeth Egede Nielsen <
[e-mail]> wrote:



Hi Mo,



Please accept the below comments to the present draft.



Having been made aware, however, of the discussion about the draft scope
and contents at IETF89 (Mirja made me aware – J),

then some of the comments below may actually not be so useful. I.e., some
parts may go away in consistency with

the comments given to this effect at IETF89.

Please see other email on this.



BR, Karen



Comments:



Usage of term “OS”: (multiple places)



In the document UDP and IP functions are consistently quoted as being OS
functions.

In user mode UDP/IP stack solutions this is not the case, meaning that here
the UDP (or IP) layer does not reside more

in OS space than the application layer does. I understand that kernel OS
UDP/IP stack solutions are widely

deployed but also User mode stack solutions exists and are getting some
momentum in these years for some of the same reasons

that implementation of transport layer in user mode has momentum.

Would it be relevant to at least make the note in the document that the
UDP/IP layer may not actually be part of the OS.

Or alternatively completely remove all notions of the OS in the document as
it wherever used seems to refer to UDP/IP stack functions.



Mo: I agree user-space network stacks should be included. “OS” was not
intended to exclude them or only encompass the kernel (although most
network stacks are in kernel space in most OS’es).

*[Karen] User mode network stack solutions do not invoke the OS IP stack
(typically in OS kernel) but instead uses the OS as an HW abstraction layer
in which to execute the user mode stack. But this is a very minor issue in
the context of this doc.*

How about if we just clarify in the initial definition of OS that this
encompasses user-space network stacks as well as traditional kernel stacks? I’m
hesitant to replace OS with UDP/IP stack in case we want to describe other
interactions, like interface-level traffic shaping which may be a lower
layer than UDP/IP functions. I guess we could go with “network stack”
though, if that is preferred over OS.



*[Karen] Either way would works fine for me. *



Then potentially  most of the OS and UDP/IP aspects of this document may
actually be removed – except for the overall setting of context which I
think is nice and beneficial.



Mo: Nothing was intended as pure context with no relevant interactions to
describe. If we remove the interactions (5.6), it probably makes sense to
remove the component completely.

*[Karen] Setting the context of a function is generally very valuable even
if not all parts/components are in scope of the work (RFC). But let’s see
what others think . References (e.g. [Singh12]) of course also can serve
for architectural context.*



Also I agree with the comment given by Lars at IETF89  that most of the
described interaction in-between the UDP/IP and the CC likely would be
handled in the CC  and the interface for the relation in between CC and
UDP/IP would be described in each CC algorithm proposals.



Mo: Yes, in most cases things like pacing/shaping for a single flow would
be done by the CC. But, as mentioned in 5.6, interface-level traffic
shaping may also be used (for local bottlenecks) if supported by the OS. *(The
network stack solution ;-).*

The text can probably be clearer on this, if we agree it is a worthwhile
thing to retain. I’m aware of implementations that do this, but they are
fairly rare, so I’m fine with omitting such interactions if we want to
simplify the draft. However, I think we should at least retain the ECN and
DSCP parts of the CC-UDP/IP interactions in 5.6.



*[Karen] I think this would depend on to which extend these CC – network
stack interactions are described in the CC algorithm proposals themselves.*

*It would be good to have comments from the CC designers on this.*



Section 4:



Would it be right to clarify that the looser model in [Singh12] corresponds
to the model in figure 2.



Mo: Yes, will do.



Section 5.4:



Allowed rate:



I know that it is merely an example. Still the one second example sounds
like a bit of a long time compared to TCP CC which operates on an RTT
granularity basis.



Mo: Agreed. There is really no need for the example, so it can be removed.



FEC: The FEC may influences the sensitivity towards certain network
impairments (potentially to be communicated to CC)  but that such
sensitivity would stem from FEC would not be exposed as the interface. Or
would it ?



Mo: I think you’re right. FEC is just a consideration when exposing Loss
Tolerance which is the real interface. Folding the FEC consideration into
the Loss Tolerance part would be clearer.



The same about the probing: If FEC is run, probing may be done in
particular manner, but it would not necessarily be exposed on the interface
between codec and CC. Or would it ?



Mo: Perhaps Varun or Lars can comment on FEC probing since they wrote a
draft on it. ;)  We should decide which is a better model, to have FEC
coupled with CC so the Allowed Rate only includes media and only increases
after successful probing, or have FEC coupled with the Codec (or RTP) but
invisible to CC so the Allowed Rate includes FEC and increases
speculatively (so the Codec/RTP must cautiously apply FEC upon speculative
increases signaled by the CC). The draft currently does the latter, but I’m
open to changing this.



Section 5.5:



I wonder if the following should not be a requirement for the RMCAT CC, and
go into that document, rather than be stated as

something to handle at the interface in between RTP and RMCAT CC:



   RTP Circuit Breakers: The intent behind RTP circuit breakers
   [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch
   of last resort, not true congestion control.  The breakers should
   never trip when an effective congestion control is operating.  This
   may impose some boundaries on RMCAT solutions to ensure the
   congestion control never approaches situations which may trigger the
   breakers.



Mo: Yes, it is more a requirement for no interaction! We can remove it
unless/until we discover some specific quantifiable boundaries that would
be dynamically imposed on the CC.

*[Karen] I think that we should have this be lifted into the requirements
doc.*



Section 5.7:



I wonder if the context here does not belong to the Coupled CC work ?



Mo: This section is really just a stub to acknowledge that interface may
exist and point to the Coupled CC draft for details.

*[Karen] Ok. We see were we end exactly in terms of scope of this doc: App*
*ß**à** CC interaction only or interactions generally between the various
components.*