Re: [rtcweb] To multiplex or not!

[Dzonatas Sol <[e-mail]>]

On 07/19/2011 05:05 PM, Cullen Jennings wrote:
> I'd like to see it that devices MUST support multiplexing and I'd probably be in favor of also MUST support non multiplexed flows. The multiplexing is a big advantage for any device that needs to deal with NATs so I suspect many "legacy" devices would be moving to this even if there was no need to deal with the browser like devices. I also think that allowing this type of multiplexing will make firewall traversal easier where a device can configure a firewall to open just one specified port and use it for RTP.
>
> The number places where RSVP is usable does not really overlap with places one uses ICE so it does not bother me in the slightest that RSVP won't work with this. It's pretty easy to imagine an extension to RSVP to support reservations based on SSRC inside the flow. Diff Serv based qos will work which is what more commonly used in situations where we are using NATs.
>
> The primary reason I want multiplexing is the time to set up all the ICE connections. The fact of the matter is that NATs limit how quickly you can create new flows. If all you need is something simple with just 2 flows, one for audio and one for video, this is workable. But as soon as you move to trying to have a transition strategy from V4 to V6 and multiple person video or even just multi screen video, the user experience goes downhill rapidly.
>    

V9 is quick, yet the impression gives the vaporware experience because 
it is solid state less-than-best solution. For real-time, probably best 
to just expose if V4 is fast or slow, and we can assume the opposite 
about V6.


> Much of the IETF thinking around ICE was done on the assumption that ICE could be done before ringing started or during ringing but the deployments I am seeing are moving more towards not doing ICE until after a call is answered. There are many reasons for this but one of them is that if Alice calls Bob, and Bob is on a mobile internet device, you don't want to reveal Bob's location to Alice before Bob even decides to answer the call. Given an IP address more or less reveals location these days that a bit of issues to do ICE before answering. This puts more pressure on being able to do ICE quickly for a good user experience.
>    

V9 crystallization technique simply wants to know if anything changed 
while 'do ICE quickly' is done. Consider that quality of service for 
dynamic-compilers, especially those that need what weight of energy 
before any real-time process is done.

If we know the process and data does not contain any location, sex, or 
age, then pressure relief exists with that process and data. I see three 
flows for ICE, not 2, and one separate individual flow.

Safe to multiplex those flows? Not by these standards in this WG.


> Cullen<with my individual contributor hat on>
>
> On Jul 19, 2011, at 7:28 , Magnus Westerlund wrote:
>
>    
>> Hi,
>>
>> This email is as an individual contributor.
>>
>> I want to get started on the discussion of the Multiplexing of the
>> various protocols over single lower layer transport flow, such as a UDP
>> flow. I will attempt to split up the questions into different emails.
>>
>> The first question I think is reasonably easy to get answered, but I
>> think it is time we determine if my belief in the answer is correct or not.
>>
>> The traffic between two RTCWEB peers from the various components, such
>> as RTP sessions, datagram service:
>>
>> a) MUST be sent as Individual flows for each component.
>>
>> b) MUST be multiplexed into a single transport flow.
>>
>> c) SHOULD be multiplexed into a single transport flow, but the RTCWEB
>> peer MUST be able to send them as individual flows.
>>
>> I would love if people can indicate their choice or preferences.
>>
>> I personally prefer A as it it is simplest in all aspect except the NAT
>> traversal.
>> - It allows for flow based QoS.
>> - It is the what the implementation that exist mostly do
>> - Signaling protocols that exist support it, no extra functionality
>> - People are used to the concept
>> - It minimizes the difference to legacy.
>>
>> Thus it is the quickest road to define something with the least formal
>> push back and concern over maturity of any solution.
>>
>> The downside with B and C is that we do have to solve the multiplexing
>> and get an agreement that gets through all the hurdles.
>>
>> Of these two opens I do prefer C.  Although it results in the extra
>> complexities of having both alternatives, it will give us both a
>> fallback, flow based QoS and better legacy support.
>>
>> Now it is your time to make your opinion heard!
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> F�r�gatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>      
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>    


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant