Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 25 February 2014 15:52 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE3A1A07C8 for <rtcweb@ietfa.amsl.com>; Tue, 25 Feb 2014 07:52:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyPhRQgOaA_B for <rtcweb@ietfa.amsl.com>; Tue, 25 Feb 2014 07:52:43 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91F1A07CA for <rtcweb@ietf.org>; Tue, 25 Feb 2014 07:52:43 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s1PFqdId022522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 09:52:39 -0600 (CST)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s1PFqdQT005691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 10:52:39 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Tue, 25 Feb 2014 10:52:39 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Richard Ejzak <richard.ejzak@gmail.com>
Thread-Topic: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
Thread-Index: Ac8xYc5b69yuJmdXSPqgdx4f9mMa8P///zaA///uN6CAAB/0AP//6jzw//+a7YD//x16EP/+ONLQ//ubSND/9sa4AA==
Date: Tue, 25 Feb 2014 15:52:38 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826DFF749D@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <7594FB04B1934943A5C02806D1A2204B1D1B4DA3@ESESSMB209.ericsson.se> <CAJuyhsz4ZG_ReNEqmu+fTcSDfXxCnKWaVBhYvjf4XsWxSXB1mQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1B5097@ESESSMB209.ericsson.se> <CAJuyhsxz4X2aDNx2Y1Y2Gi9G0D12Ort95QFD=cQ6s-zM5GK9Uw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1B5305@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFF58DB@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1B59FA@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17826DFF5D26@US70UWXCHMBA02.zam.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1B839A@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PoYNT8bt7vhKXrsZusoHWbyHO_c
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] A few questions on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 15:52:45 -0000

Hi Crister,

Thanks.
Please see my comments inline.

> Hi Raju,
> 
> >> Anyway, can you give me an example of a case where you want to use
> >> SDP, and where you need to negotiate the re-transmission values etc?
> >
> > [Raju] A simple example would be 2 browsers talking thru an intermedia
> proxy, which wants to know what protocols are
> > being negitiated and used as part of the session.
> 
> Sure. I don't question the use-case/need for using SDP to negotiate channel
> usages.
> 
> > 1. Calling client creates data channel (using
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel)
> with desired
> > attributes and sets negotiated=true. So, calling browser saves the
> attributes for the data channel but won't use DCP.
> > 2. These attributes are sent via SDP to peer client (via proxy).
> > 3. Peer client sets these same attributes while creating data channel and
> sets negotiated=true but won't do DCP.
> > 4. Peer client echo the same attributes back in SDP answer.
> >
> > Now, data channel stacks on both ends will use same attributes, similar to
> DCP use case, with the only difference being DCP is not used here.
> 
> My question was regarding the re-transmission values etc.
> 
> Why do the peers need to negotiate those? Why would an intermediary need to
> know about those? Why not simply define those in the protocol description,
> and each endpoint supporting the protocol will then know what values to use?

[Raju] Peers need to negotiate those so that both ends of the data channel can use same timers (similar to DCP).
Intermediate entities pass these values to the peer in some cases and need to know these in other cases so that they can be passed down to data channel entity which is terminating the data channel (and interworking to other transports like TCP).
IMHO, these attributes are specific to data channel thus they should remain associated to data channel (DCP or external negotiation; making them part of other protocols is not only wrong but also causes unenecessary modifications adding overhead to these protocols.

Best Regards
Raju