Re: [AVT] Port mappings, NAT, and RAMS
Roni Even <Even.roni@huawei.com> Wed, 01 July 2009 05:01 UTC
Return-Path: <Even.roni@huawei.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8526A3A6ECA for <avt@core3.amsl.com>; Tue, 30 Jun 2009 22:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1ohETmZlLz5 for <avt@core3.amsl.com>; Tue, 30 Jun 2009 22:01:56 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 71F443A691B for <avt@ietf.org>; Tue, 30 Jun 2009 22:01:56 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM300HJU7BSQ2@szxga03-in.huawei.com> for avt@ietf.org; Wed, 01 Jul 2009 13:02:16 +0800 (CST)
Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KM300HCE7BSJL@szxga03-in.huawei.com> for avt@ietf.org; Wed, 01 Jul 2009 13:02:16 +0800 (CST)
Received: from windows8d787f9 (bzq-82-81-144-74.red.bezeqint.net [82.81.144.74]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KM3003NH7BFHA@szxml02-in.huawei.com>; Wed, 01 Jul 2009 13:02:16 +0800 (CST)
Date: Wed, 01 Jul 2009 08:01:50 +0300
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <3B2FD2F513F8E1468C1A9FAE0C61BF2F15ED30B5@tk5ex14mbxc105.redmond.corp.microsoft.com>
To: 'Zeev Vax' <zeevvax@microsoft.com>, "'Bill Ver Steeg (versteb)'" <versteb@cisco.com>, "'Dave Oran (oran)'" <oran@cisco.com>
Message-id: <017f01c9fa09$1317db30$39479190$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-us
Content-transfer-encoding: 7bit
Thread-index: AQHJ+XGL55qnQXLLnEGrAy1spvMJMJBfirkA//+t9sCAADJukIAAYNvwgABSz+A=
iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated.
References: <mailman.10085.1245185397.4936.avt@ietf.org> <238382595265324EA50F6134BB42DCAF04046DCF@FRVELSMBS22.ad2.ad.alcatel.com> <015d01c9ef3e$13f25830$3bd70890$%roni@huawei.com> <238382595265324EA50F6134BB42DCAF040470B3@FRVELSMBS22.ad2.ad.alcatel.com> <04CAD96D4C5A3D48B1919248A8FE0D54098D86E4@xmb-sjc-215.amer.cisco.com> <81B9B88E2F9D574AA5328A85547CDE910174E7C8@xmb-rtp-21d.amer.cisco.com> <3B2FD2F513F8E1468C1A9FAE0C61BF2F1174CCA3@tk5ex14mbxc105.redmond.corp.microsoft.com> <025401c9effa$34040170$9c0c0450$%roni@huawei.com> <3B2FD2F513F8E1468C1A9FAE0C61BF2F15EC5C1E@tk5ex14mbxc105.redmond.corp.microsoft.com> <04CAD96D4C5A3D48B1919248A8FE0D540995BF39@xmb-sjc-215.amer.cisco.com> <3B2FD2F513F8E1468C1A9FAE0C61BF2F15EC6F77@tk5ex14mbxc105.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91017F57DA@xmb-rtp-21d.amer.cisco.com> <238382595265324EA50F6134BB42DCAF04137224@FRVELSMBS22.ad2.ad.alcatel.com> <04CAD96D4C5A3D48B1919248A8FE0D54099DFD1A@xmb-sjc-215.amer.cisco.com> <"04CA D96D4C5 00C4"@xmb-sjc-215.amer.cisco.com> <238382595265324EA50F6134BB42DCAF04186C7F@FRVELSMBS22.ad2.ad.alcatel.com> <04CAD96D4C5A3D48B1919248A8FE0D5409A71F22@xmb-sjc-215.amer.cisco.com> <00e601c9f971$6a7b0e80$3f712b80$%roni@huawei.com> <83D31F7D-8D4C-44D1-9AD3-814C4776922F@cisco.com> <3B2FD2F513F8E1468C1A9FAE0C61BF2F15ED2A46@tk5ex14mbxc105.redmond.corp.microsoft.com> <81B9B88E2F9D574AA5328A85547CDE91018C6ABD@xmb-rtp-21d.amer.cisco.com> <3B2FD2F513F8E1468C1A9FAE0C61BF2F15ED30B5@tk5ex14mbxc105.redmond.corp.microsoft.com>
Cc: 'VAN CAENEGEM Tom' <Tom.Van_Caenegem@alcatel-lucent.be>, avt@ietf.org
Subject: Re: [AVT] Port mappings, NAT, and RAMS
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 05:01:58 -0000
Zeev, The IETF has worked on it as part of BEHAVE WG and defined ICE for SDP based systems Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Zeev Vax > Sent: Wednesday, July 01, 2009 4:13 AM > To: Bill Ver Steeg (versteb); Dave Oran (oran); Roni Even > Cc: VAN CAENEGEM Tom; avt@ietf.org > Subject: Re: [AVT] Port mappings, NAT, and RAMS > > I agree IETF is the right form, but I'm not sure the AVT WG is the > right form as I think it is more general problem. > > Zeev > > -----Original Message----- > From: Bill Ver Steeg (versteb) [mailto:versteb@cisco.com] > Sent: Tuesday, June 30, 2009 2:14 PM > To: Zeev Vax; Dave Oran (oran); Roni Even > Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; avt@ietf.org > Subject: RE: [AVT] Port mappings, NAT, and RAMS > > I agree that we should make a general solution for mapping unicast > sessions onto unicast sessions. > > We need to solve this problem using data flows that will work across > multiple vendors' solutions, and thus need to do it in a standards > forum. The IETF is the correct place to do this. > > Bill VerSteeg > > -----Original Message----- > From: Zeev Vax [mailto:zeevvax@microsoft.com] > Sent: Tuesday, June 30, 2009 9:07 AM > To: Dave Oran (oran); Roni Even > Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg > (versteb); > avt@ietf.org > Subject: RE: [AVT] Port mappings, NAT, and RAMS > > I agree this should be a separate draft and we should work on a more > generic mechanism. > Two comments I have, first being a general problem it might have been > solved already so I think we should research the area before investing > in another draft. Second given such functionality is typically part of > an application and not staying only in the lower network layers, the > application can solve it as part of the startup sequence or other data > delivery mechanism it has. > > Zeev > > -----Original Message----- > From: David R Oran [mailto:oran@cisco.com] > Sent: Tuesday, June 30, 2009 6:10 AM > To: Roni Even > Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg > (versteb)'; Zeev Vax; avt@ietf.org > Subject: Re: [AVT] Port mappings, NAT, and RAMS > > > On Jun 30, 2009, at 6:55 AM, Roni Even wrote: > > > Hi guys, > > My view is that this is not a general NACK problem but only for the > > case of SSM and retransmission with similar box architecture to the > > RAMS solution. > > If you have another case please explain > I believe it is actually a MORE general problem than NACK or RAMS. I > arises from mixing SSM sessions and unicast sessions for the same RTP- > based application. That's because multicast enforces port symmetry > among > all the receivers while unicast needs per-receiver port selection. > > So far we have two uses for mixing multicast and unicast: > retransmission-based repair, and RAMS. I suspect more uses will arise > in > the future. I can think of a few off the top of my head: > - customized per-user overlays (e.g. to be alpha-blended with the > video) or object-level replacement > - network-coded error recovery streams > - extra media info for re-integration when switching back from unicast > to multicast in a fast-forward-to-realtime capability when doing > "pause-live-content" style services > - adaptive switching between multicast and unicast based on number of > simultaneous receivers. > > I have a strong intuition that doing a generic mechanism to atomically > signal ports for unicast sessions using the RTCP feedback machinery of > the SSM session would be highly advisable. > > So, I think: > a) we need to solve this problem > b) it exists even in the absence of NATs > c) we need a generic mechanism > d) it should be documented in a separate draft, and not part of RAMs or > AVPF. > > If we can agree to these points, then we can have a more detailed > discussion of the appropriate machinery. I have opinions on that > subject > too. > > DaveO. > > > > > Roni > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf > Of > > >> Ali C. Begen (abegen) > >> Sent: Tuesday, June 30, 2009 10:19 AM > >> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even; > >> avt@ietf.org > >> Subject: Re: [AVT] Port mappings, NAT, and RAMS > >> > >> Hi Tom, > >> > >> Let's get the input from the WG on these points. I believe going for > >> a more general solution that will be applicable to both RAMS and > NACK > > >> is more desirable. > >> > >> BR, > >> -acbegen > >> > >> > >> > >>> -----Original Message----- > >>> From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem@alcatel-lucent.be] > >>> Sent: Monday, June 29, 2009 9:17 AM > >>> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; Roni > >> Even; avt@ietf.org > >>> Subject: RE: Port mappings, NAT, and RAMS > >>> > >>> > >>> Ali, > >>> > >>> See some comments below (TOM). > >>> > >>> -----Original Message----- > >>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >>> Sent: vrijdag 26 juni 2009 17:41 > >>> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni > Even; > > >>> avt@ietf.org > >>> Subject: RE: Port mappings, NAT, and RAMS > >>> > >>> Hi Tom, > >>> > >>> [snip] > >>>> The reason why we need pubports is that it indicates "explicitly" > >> the > >>>> port the client wants to use to receive the burst is the port it > >> used > >>>> to send the RAMS-R/pubports message. I believe we need this > >> explicit > >>>> indication, ow, we will be making an implicit assumption. Note > that > > >>>> the rams-r/pubports is in the primary session and burst/ret > packets > > >>>> are in the retransmission session, which is different than the > >>> primary. > >>>> > >>>> As far as I can see, not everybody agrees on this point, but we > >> need > >>>> to make a decision here before we mandate anything. > >>>> > >>>> TOM: I agree with your last line, but I do not completely agree > >> when > >>>> you mention "implicit" assumption, especially for option 3, where > >>>> RAMS-R (or > >>>> NACK) and the Pub-port message are in the same compound message. > If > >> we > >>> > >>>> "define" that if no pub-report message is sent by the RR, the > >>>> information towards the Retransmission server is exactly the same > >> as > >>>> when an RTP receiver sends an RTCP compound message made up of an > >> RTCP > >>> > >>>> NACK/RAMS-R together with a pub-port message where the ports are > >>> "zero" > >>> > >>> We "may" be able to say it from RAMS-R but not for NACK since we > are > >> not > >>> defining it, we will be overloading its meaning, IMO. And as you/ > >>> Bill pointed out in other emails, I also believe that this is more > >>> general problem than just RAMS. We need something like pubports for > >>> NACKs as well. > >>> > >>> > >>> TOM: indeed, that is why IMO we should define this problem and > >> solution > >>> in a separate draft which applies to any system architecture where > a > > >>> unicast session from a FT is coupled to a ssm session with that > same > >> FT. > >>> > >>> > >>>> -as currently proposed in the RAMS draft now. I agree that this > is > > >>>> not true for option 4, where pub-port and RAMS-R or NACK are > >> separate > >>>> messages, but I do not favour the solution of option 4 for the > same > > >>>> reason you mention in your reply (a new failure mode). So, if > >> option 4 > >>> > >>>> is -for that reason- no longer considered, I do not see a problem > >> with > >>> > >>>> defining this rule/clause as expressed above. In other words, > there > >> is > >>> > >>>> no need for a pub-report message in this scenario and this results > >> NOT > >>> > >>>> in an "assumption" what-so-ever. > >>>> > >>>> > >>>>> supports RTP/RTCP muxing itself, and if it knows the RS supports > >>>>> RTP/RTCP muxing too (as indicated in the declarative sdp received > >> by > >>> > >>>>> the > >>>>> RR) > >>>>> > >>>>> -Don't we also allow that for option 3, the port P2 actually > >> equals > >>>>> port P4? This is a kind of hybrid of session and SSRC > >> multiplexing > >>>>> of the primary multicast RTP stream and the > >>>>> retransmission/acceleration session > >>>>> : on the unidirectional RTP layer, the primary MC packets and > >> the > >>>>> unicast retransmission packets are clearly session muxed, but the > >>>>> RTCP > >>>> > >>>>> "return" channel for both streams have exactly the same transport > >>>>> addresses, but are distinguished by means of a different SSRC. > >> In > >>>>> that > >>>> > >>>> How? Since SSM and retransmission sessions are session muxed, they > >>>> have the same SSRC. When a client is sending a receiver report, > how > >> do > >>> > >>>> we identify which session it belongs to? So, I believe P2 should > be > > >>>> different than P4. > >>>> > >>>> TOM: you are right. But notice this: RFC 4588 mandates that when > >>>> session muxing is used for retransmission, than the SSRC should be > >> the > >>> same. > >>>> However the RFC 4588 does not give arguments why it needs to be > >> like > >>>> that. So I ask you: what would or can happen if there is a > >> different > >>>> SSRC used? If there are no convincing arguments why we must stick > >> to > >>> > >>> Good question. If we don't use the same SSRC in session-muxed RTP > >>> sessions, it will introduce correlation problems. Receiver/XR > >>> reports coming from a larger number of receivers will be difficult > >>> to > >> identify > >>> and match at the server side. There will be SSRC collisions, which > >> will > >>> complicate things further. > >>> > >>> TOM: the big difference with when the RFC 4588 was being discussed > >> and > >>> developed, is that now we are capable of advertising in SDP the > SSRC > >> of > >>> the media server, that is in this case the retransmission server > >>> SSRC used in the retransmission session. In fact for RAMS, we need > >>> to > >> define > >>> the SSRC of the ssm RTP session, so we can as well do it for the > >>> retransmission session. Perhaps we should consider this different > >> SSRC > >>> possibility (hence violating RFC 4588) as part of a new draft, the > >> one I > >>> mentioned above. > >>> > >>> > >>>> the same SSRC, then, if we have a good use case to depart from > that > > >>>> "rule" -and the use case we are discussing here is IMO indeed a > >> valid > >>>> use case- I do not see why we should be limited by such a "rule". > >> The > >>>> "valid" use case is here that RAMS and Retransmission for SSM > >> sessions > >>> > >>>> operates fine through any NAPT and without any dedicated RTCP > >> message. > >>> > >>> -acbegen > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt
- [AVT] comments on section 10 of draft-ietf-avt-ra… Roni Even
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… Ali C. Begen (abegen)
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… Roni Even
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… Ali C. Begen (abegen)
- Re: [AVT] comments on section 10 of draft-ietf-av… VAN CAENEGEM Tom
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… Roni Even
- Re: [AVT] comments on section 10 of draft-ietf-av… Roni Even
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… VAN CAENEGEM Tom
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… Ali C. Begen (abegen)
- Re: [AVT] comments on section 10ofdraft-ietf-avt-… Ali C. Begen (abegen)
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Bill Ver Steeg (versteb)
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Zeev Vax
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… Roni Even
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Roni Even
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… VAN CAENEGEM Tom
- Re: [AVT] comments on section 10ofdraft-ietf-avt-… Bill Ver Steeg (versteb)
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Zeev Vax
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Ali C. Begen (abegen)
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Zeev Vax
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Ali C. Begen (abegen)
- Re: [AVT] comments on section10ofdraft-ietf-avt-r… Zeev Vax
- Re: [AVT] comments on section 10 ofdraft-ietf-avt… Ali C. Begen (abegen)
- [AVT] Port mappings, NAT, and RAMS Bill Ver Steeg (versteb)
- Re: [AVT] Port mappings, NAT, and RAMS VAN CAENEGEM Tom
- Re: [AVT] Port mappings, NAT, and RAMS Ali C. Begen (abegen)
- Re: [AVT] Port mappings, NAT, and RAMS Dan Wing
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS VAN CAENEGEM Tom
- Re: [AVT] Port mappings, NAT, and RAMS VAN CAENEGEM Tom
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS VAN CAENEGEM Tom
- Re: [AVT] Port mappings, NAT, and RAMS (or is it … Bill Ver Steeg (versteb)
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS VAN CAENEGEM Tom
- Re: [AVT] Port mappings, NAT, and RAMS Ali C. Begen (abegen)
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS Zeev Vax
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS Zeev Vax
- Re: [AVT] Port mappings, NAT, and RAMS VAN CAENEGEM Tom
- Re: [AVT] Port mappings, NAT, and RAMS VAN CAENEGEM Tom
- Re: [AVT] Port mappings, NAT, and RAMS Ali C. Begen (abegen)
- Re: [AVT] Port mappings, NAT, and RAMS Zeev Vax
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS David R Oran
- Re: [AVT] Port mappings, NAT, and RAMS Zeev Vax
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS Bill Ver Steeg (versteb)
- Re: [AVT] Port mappings, NAT, and RAMS Bill Ver Steeg (versteb)
- Re: [AVT] Port mappings, NAT, and RAMS Zeev Vax
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even
- Re: [AVT] Port mappings, NAT, and RAMS Zeev Vax
- Re: [AVT] Port mappings, NAT, and RAMS Roni Even