Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 11 September 2020 07:40 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9893A0A16; Fri, 11 Sep 2020 00:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 KqpeXzCb9Mai; Fri, 11 Sep 2020 00:40:09 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60053.outbound.protection.outlook.com [40.107.6.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC403A0A13; Fri, 11 Sep 2020 00:40:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ETKhhljmOQv3bZdddXEZ91hjv3pcJDI+DZUXL64HP40q35UtG4C0Ecp20HL5icU32g4XbQxYqI25UNiQisbJJRtU7TuNnw0Lj4wG8y04irNp+M2UeDdRP1ByN3A7pTe7bprhvr1I1Y288NYk7EIzOSar0nmZUUcVd7hQ3AaA974JjgcUyqSYNlWGkJ4TjvvZzk5xCGNk1mbqx3EFINDezNNBr+samN6go3lmaAyDcN4+ydvbITdZCuDJQkcUT6QTu4xfm7PZmxQiMJ+fiK7+tdwKvcnMOtmfKqydmEJBcxRvELQm2LnUQC11bEQOTGAcn1kv8ki/dKLveoFdVBHAnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KM386ZxFTWPB1cXpejO0ILc2YlDpUN972pCvgCf8SFQ=; b=doYtmxlEk2XS+1yLc24yjHjRo8QCfKXeEInN01GplF/g1G1Q4m9MxSA6T5kZp/0pGEqWDPX2WdF+po+4V2FxvShr8dgVPNrX6OiI6hyxE80jfQ4jFLUe0xt0zj3lNisUKm1FLXtDxwtCu6cLFJoWiHfBo6BbEVRnVr0ZYBmx22qq5aNV2MmImskwuz3hZt0u4LGN6Jq4lyhliSPYG38q9FDfU6uja52beXy5d4TN2UEo6SMJ3XOCdlO4RMSKqOIllo4vgqAHM+s50FDyr1YU0lKbxnwxImS8i4XUiGhJbbDpCfM/U2Ao6Ixwyp22C5CcmeK4TrrszEw6alGQZipDFw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KM386ZxFTWPB1cXpejO0ILc2YlDpUN972pCvgCf8SFQ=; b=HhqMFOokCUTNzXVPQRNi+k3JXb08H7RjfzxTa36FEJiIk6vHDonrLv/gx1I494hEA4REn+HrXblBdn6kISPdUtCOandDZC63/+J8h2E4X2PtzPVNcyrPJCbIt2Kjky1gEz1Xzme5GWQ73SGkhRTPszvh2MgUUbPK2nAHZYlVeJI=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4444.eurprd07.prod.outlook.com (2603:10a6:7:a0::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.4; Fri, 11 Sep 2020 07:39:34 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::b56f:9a8e:3399:aaa3%7]) with mapi id 15.20.3370.016; Fri, 11 Sep 2020 07:39:34 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "sergio.garcia.murillo@cosmosoftware.io" <sergio.garcia.murillo@cosmosoftware.io>, "rlb@ipv.sx" <rlb@ipv.sx>
CC: "dispatch@ietf.org" <dispatch@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "sframe-chairs@ietf.org" <sframe-chairs@ietf.org>, "sframe@ietf.org" <sframe@ietf.org>
Thread-Topic: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
Thread-Index: AQHWhTXfuLaYkFC4LEWqC8j5AGiLAKlh8DkAgAASwICAALgzgIAAV8mA
Date: Fri, 11 Sep 2020 07:39:34 +0000
Message-ID: <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com>
References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <CAL02cgS=y7mBt10n+jCGwUoy54eeH9ZXFijQdDSKk5Qt9mNrUw@mail.gmail.com> <e0b5dc1c04ab6b5cee2c88b5b1b348d7c70a5d4c.camel@ericsson.com> <a3fbe87c-d60b-23f1-2968-c7ac6ad50ea4@cosmosoftware.io>
In-Reply-To: <a3fbe87c-d60b-23f1-2968-c7ac6ad50ea4@cosmosoftware.io>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: cosmosoftware.io; dkim=none (message not signed) header.d=none;cosmosoftware.io; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.116.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 01f90f7b-35a8-4eb7-abff-08d85625d45a
x-ms-traffictypediagnostic: HE1PR07MB4444:
x-microsoft-antispam-prvs: <HE1PR07MB4444706304485F7ACFB0329495240@HE1PR07MB4444.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: IUPqbMFE0sOFI7YY/K9cVyKYFp+oPQvlnm5u9Jy92Rj+IrYn6GuMMN8cqmZkN5cpmoX14HwaHpCxRRV5sjiJu7+cJUWPxBQJicIpuEzI9sL6Ej76F2E6nc8j/naG4iF6TZG/fbDUa6dGD0mgF6SS09zBSYGfUWUU2i/uT/fXUT1KjYyn2PPD63zg6OlhTPJacQy1Vxk6q62zSr0QUxk7OABDNc6/3vsEVIa/rmjz+sq17CTzfIV2psACGZFGFAfjsV6T7T9YmEbImrBE2a9+8lxXp7xEQe9ocRNpCl2C1AnEuPrumU3qYAnt6rpxi5y1ZiXCb0AVBykurWXEbzdfNuIJejJBlq5FfYH6JY0R3ycso/bQViJr6SF1swshz1TK
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(346002)(396003)(376002)(186003)(5660300002)(6512007)(44832011)(8676002)(6506007)(110136005)(26005)(478600001)(53546011)(2616005)(66446008)(66476007)(2906002)(86362001)(36756003)(316002)(76116006)(66946007)(4326008)(71200400001)(66556008)(8936002)(54906003)(6486002)(64756008)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: cUT8ajuzvFobvnMJGFWE2KQwPFcOVrIb/jaL/fL0F4t2y4xi6nKbDKqm2MNlSAsBJSaRdLn+zSHsl79dYOgDLbYLhEow+mDb179Uwy4kZHZ8RB5gdqKsHOgiUsJYFBR6pJjoThLebJJcfwqf00KK/rk+NO0xpZU2G6klGCiBCvN4RfNPRvdCGlKxEOoeQUkIuKSt1tptnWf6M73omjc3xzNHScx9aUjbu3kpyWWhA797HmjU2VCqm+LbDDSkj4cPPXJhCIql/509Th8ivSSoCRxLSGDpxmfnDFnyYVPQioVJFd7JfcTCVI2PYLcDqtoa8BiJ68JTVrdMvWt3UKOG3hD2t3BkcDLLScJZScK4Y7aJfb9P+SFlzuHPvTiu1W8rTgxaZZOC04HcxWjD1ccKX3D1PyKyCRT+UP/9omD1Dz5LC4uafqMUgYTP1vDtmbnwpQBdiFiBzSCJNQujoi9xboRyKJv7b1bEiH3OoSNKdJ+yxaZApfACBhxd9jXxAaHUR837ITmrKRAOPrBCIvdPgFwdvwg0ij1fjB8FjIFU3cX3fknF0hnlyh9tq9xiajZm+uHeVm7c6BIDkz9VtSBiNMy/uyxm3nkk1UKgaO47kWXhx0jI6Vu8jjvVoTsuL5xsrWGx3D/0NJ6IYNtF2UndBw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C08809BFBB84544B8CE6BE6D42F31D12@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 01f90f7b-35a8-4eb7-abff-08d85625d45a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2020 07:39:34.8666 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: py9ekZGDQaR0ekT69dYEN2IfyCya7Ry2kwZS3nh8+06MhYu9vz56QpdeAcryUZhURSmempVhXDkK2/euxn+PVbIsBB+prfn8IvVr2+ktZdQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4444
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/zx3fe5CzsHOELSMgezm8Gr6nDaw>
Subject: Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2020 07:40:11 -0000

Hi,

I think we are making good progress here. 

On Fri, 2020-09-11 at 04:25 +0200, Sergio Garcia Murillo wrote:
> On 10/09/2020 17:26, Magnus Westerlund wrote:
> 
> > [...] However, the issue I really reacted to here is the fact that the
> > charter is
> > stating that it should do an RTP payload format. When doing an RTP payload
> > format I think it is pre-mature of the charter to say that the signalling
> > required for the RTP payload foramt is out of scope. I think that needs to
> > be
> > part of the process to discuss in the RTP payload format how an RTP
> > middlebox
> > can use the payload format, and any RTP extension like frame marking to
> > figure
> > out what to do when switching. That RTP payload format will require some
> > configuration capability to be able to work.
> > 
> > So what I am really asking for is the removable of the restriction that
> > prevents
> > a regular RTP payload format design work. And stating that SDP is out of
> > scope
> > implies that to me in the direct context of the payload format.
> 
> 
> I agree. As I read the charter, SDP is out of the scope for 
> negotiating/signaling the usage of SFrame and the parameters that may be 
> used for encryption/decryption.

The signalling for what is in the SFRAME is out of scope also. 

So do I assume correctly that the idea is that the application layer using
SFRAME if it haves multiple independent or sets of dependent streams there will
be no support for that aspect in SFRAME layer? Instead it is up to the
application to put such information to either put it inside the encapsualted
part of the SFRAME or map it to the lower transport layer, like to RTP SSRCs and
extension information. 

> 
> However, if the encrypted output is going to be transmitted over RTP 
> using a new packetization format, we need to address how to negotiate 
> that in the SDP.

Good

> Note that this new packetization format will not only be alid for 
> transporting encrypted frames (SFrame or not) but even any other 
> audio/video frames.

I understand the potential exists. However, the recommendation for RTP has been
to try to consider Application Level Framing. In the case of SFRAME that
consideration moves up above SFRAME in the choice of how data is split into
SFRAMEs. However, having an RTP paylaod format for SFRAME, then that should
carry SFRAMEs. If you starts putting in other binary objects into it, then you
create a new demultiplexing point for format between the RTP payload format and
the SFRAME processing. That appears unmotivated. 

> 
> 
> > [...]
> > Maybe one way forward is to break the paragraph talking about signalling and
> > RTP
> > payload format into two different paragraph. Where the RTP payload format
> > need
> > for signalling is not associated with the higher level need for SFRAME
> > signalling over for example a SIP system. Which I am fine with excluding
> > explicitly.
> > 
> > So just talking about the RTP Payload format. I think this do need a model
> > for
> > how an RTP SFU is going to be able to do switching on it. Shouldn't that be
> > in
> > scope?
> 
> Note that the RTP payload format may not be the one providing the 
> switching information for an SFU. It is much cleaner to carry that 
> information in a new (hop-by-hop encrypted) header extension so the 
> payload does not need to be parser by the SFU at all, so the 
> packetization can be "payload-agnostic".


Yes, I agree that putting the layer dependency information into an payload
external header extension etc is very reasonable. However, the RTP payload
format will need to discuss this need and potentially recommend a particular
method for carrying the dependency information within RTP.

So to conlude I think there is one charter related question here.

Should the RTP payload format aspect of the charter be more explicit in that it
needs to disucss the general model of how to use SFRAME and how an application
can use the facilities of RTP to get good performance from RTP mechanism like
FEC and retransmission? 

 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------