Re: [Lsr] Dynamic flow control for flooding
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 24 July 2019 19:12 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA15120682 for <lsr@ietfa.amsl.com>; Wed, 24 Jul 2019 12:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=L+Ld7+O8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aGhxphr8
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 QvE0QYZhuS6r for <lsr@ietfa.amsl.com>; Wed, 24 Jul 2019 12:12:18 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957A8120663 for <lsr@ietf.org>; Wed, 24 Jul 2019 12:12:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8798; q=dns/txt; s=iport; t=1563995538; x=1565205138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FUyQs9OAipH9HpYKvQgPJcv46kVspx6sYjMgJzLUkis=; b=L+Ld7+O8HfByJfFL+WMdFMZxaTUyPyZ2vNrTqpEwv0jsp6K3i5WQiapJ gm08E9MwJBvoQzkFNeq+zX0/bA4UJL5tDpYY0ClVLmO1aFEIwcvvUSjpj 34PacYBm4ag0bBFvAjiHzjenqMYjfHTF9FacPdLQd1WDag/z/cjNPr8S4 I=;
IronPort-PHdr: 9a23:vB+PMBZwJHMywRDS7VvsPm7/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavlbiohFslYW3du/mqwNg5eH8OtL1A=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAAAyrThd/51dJa1lGQEBAQEBAQEBAQEBAQcBAQEBAQGBVQIBAQEBAQsBgUMpJwOBQiAECyqEHYNHA4x8gluXUIEugSQDVAkBAQEMAQEtAgEBhEACF4JCIzYHDgEDAQEEAQECAQZthR4MhUoBAQEBAgESEREMAQE3AQQHBAIBBgIRBAEBAwImAgICMBUICAIEDgUIGoRrAw4PAQKRB5BgAoE4iGBxgTKCeQEBBYUIGIITCYEMKAGEcoZtF4FAP4EQAUaCHi4+hEYVD4JlMoImjFqCIoUiiEmOCAkCghmLBHSIM5gKpQsCBAIEBQIOAQEFgVYBMYFYcBWDJ4JCgSYBCAGCQYNGhw1ygSmNXQEB
X-IronPort-AV: E=Sophos;i="5.64,303,1559520000"; d="scan'208";a="606811975"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2019 19:12:17 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x6OJCH2X001606 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jul 2019 19:12:17 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 14:12:16 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Jul 2019 14:12:16 -0500
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Jul 2019 15:12:16 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W924mgzWzcB8mJqgjtjjHSwB1STL8vrGONn+sSPcwkBPm2It/oQHx4+ZkeN+tmDIUkaBVXhYzGAdYOOyaroFu/RJ1NnGDh5qp86XdrLHZOBc9QEh6l5bFTTytRoc4jKx5vcMNXQPKh430KrULzU9mZY26U8NdoYydEW5h5+VgIUAoy4TqCzP+iCSGFVZouW8BqK6JIbty0vKzBR0n14rMSl+zedEkB/6Yt4SXPPXBH9oDf+/5fR5eVq8K+l4MEXh+39iQvqRyjU9ZeVslznMEdAlz9t7dHHLkiMS6C+gnuUVOQISpSRhFtWuuBJOQIT0q4N8ur3ydu288KFvAxB7ng==
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=FUyQs9OAipH9HpYKvQgPJcv46kVspx6sYjMgJzLUkis=; b=KhxIVPIRsRWmaV9fKte5lgLIRP+H6CPpE7e9sK1MC36N4cTz4C/whOqVeIw1fIWd6Wu14oUfpBsU7h5NbJe6E9tKlhCMC7wgTBSR/834YQLWDTUft3xryVii1bNEtSvOvxLJ0lCExlpSYScxFDBWJSJvjDr0IKFiohZ2khAAN8uuczQhETnT/yuTSKOABHWJqdiVxbouc7puW/TZ+WqFLZatPRPhFzT40dGLj1ygZaR/LUI26UOo/Hj1Ip40GDa4l+Lif1R6R3OCqhUheAJrIUT1U4HQncyjtwEQ/Zc0KqibN5bum12TjDBSFKgsvMDc8ZNcuYJ8fEPQzYsmfVPxCQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FUyQs9OAipH9HpYKvQgPJcv46kVspx6sYjMgJzLUkis=; b=aGhxphr85Pp9Q5fs0HCS9eLSNa9RMqhD6040Qy0wfDK5sOHyeiG4D772JcF8CB3o/ZdvXDahk/nHZA3d1TYKNOteW8COfmDXFCj257qleYiqpL9NzYsXGF5E8CF542lU0ZxHVUV8avSLwZ15vjnG65xVKuyJV+qEKeohCT9oAa0=
Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2885.namprd11.prod.outlook.com (20.177.225.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Wed, 24 Jul 2019 19:12:12 +0000
Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::c8b3:b0b0:581d:e1ce]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::c8b3:b0b0:581d:e1ce%6]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 19:12:12 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Henk Smit <henk.ietf@xs4all.nl>
CC: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Dynamic flow control for flooding
Thread-Index: AQHVQVt0dc+yhfYADEyrMMJ609g9uKbYO7RggAD4DICAAAX00IAAiA6AgABhKUA=
Date: Wed, 24 Jul 2019 19:12:12 +0000
Message-ID: <BYAPR11MB36388446EBAF9B7DDE2F2765C1C60@BYAPR11MB3638.namprd11.prod.outlook.com>
References: <CAMj-N0LdaNBapVNisWs6cbH6RsHiXd-EMg6vRvO_U+UQsYVvXw@mail.gmail.com> <BYAPR11MB36382C89363202D1B5659614C1C70@BYAPR11MB3638.namprd11.prod.outlook.com> <5841_1563943794_5D37E372_5841_105_1_9E32478DFA9976438E7A22F69B08FF924D9C373E@OPEXCAUBMA3.corporate.adroot.infra.ftgroup> <BYAPR11MB363856BB026992DFBB3BB224C1C60@BYAPR11MB3638.namprd11.prod.outlook.com> <8376a87831ffa6f5298c5122907c6e66@xs4all.nl>
In-Reply-To: <8376a87831ffa6f5298c5122907c6e66@xs4all.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com;
x-originating-ip: [2001:420:c0c8:1006::374]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 772d22aa-598d-461b-5bd1-08d7106ad4f8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2885;
x-ms-traffictypediagnostic: BYAPR11MB2885:
x-microsoft-antispam-prvs: <BYAPR11MB2885D1B3B304D846FA28F85FC1C60@BYAPR11MB2885.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(39860400002)(376002)(366004)(199004)(189003)(13464003)(486006)(46003)(476003)(11346002)(14454004)(446003)(53546011)(66946007)(6506007)(76116006)(316002)(5660300002)(7736002)(66476007)(305945005)(66556008)(64756008)(66446008)(52536014)(102836004)(71190400001)(71200400001)(81166006)(74316002)(8676002)(76176011)(53936002)(81156014)(186003)(99286004)(4326008)(561944003)(33656002)(7696005)(6246003)(25786009)(8936002)(6916009)(478600001)(9686003)(54906003)(256004)(14444005)(86362001)(2906002)(6436002)(229853002)(66574012)(68736007)(6116002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2885; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: sGqTXe1MzxjjFEMPiMgqxkfe7rSaGHWQGoCw5OkwVRtvD1xM7z2MHOLNJpKvoYU0EhtqgZ45TJynIFGQKI/MKwNQFhEHqnCGevBZA2kgajv3pUoR3cPKJOs11Xp61iuuqztYMn+Kmm9baVgfQ5uew52PgIbZF+v2HvxFWgzNNfxuqzfk308sCx5nW0cfkD1VVHAdRXZ2xJMcoiE1kjnxpjEi+UYkSk/xuw0xsUJo33YWGO2tte4Qy+ZWJHEEv2f01aXLFPQ6nv/EFcui1Q7iSrV6xH8fUVWHZoarq+tSpdiehEuujf4owIBKe75teJyCISmcYOixVCcVA+Wqn1R1LgOt/v27QA6QnkaYtactPQfaz+VkjCt+fIlhpZrn8biXSR+OwlF8BcnjTnnw4zCaBayrc6sAiN0WGdwJ5LCj094=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 772d22aa-598d-461b-5bd1-08d7106ad4f8
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 19:12:12.0619 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ginsberg@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2885
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/WjD97BV8Whj5Jw3NPsI9JPtUukU>
Subject: Re: [Lsr] Dynamic flow control for flooding
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2019 19:12:26 -0000
Henk - Inline. > -----Original Message----- > From: Henk Smit <henk.ietf@xs4all.nl> > Sent: Wednesday, July 24, 2019 6:18 AM > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com> > Cc: stephane.litkowski@orange.com; Tony Li <tony.li@tony.li>; lsr@ietf.org > Subject: Re: [Lsr] Dynamic flow control for flooding > > > Hello Les, > > Les Ginsberg (ginsberg) wrote on 2019-07-24 07:17: > > > If you accept that, then it makes sense to look for the simplest way > > to do flow control and that is decidedly not from the RX side. (I > > expect Tony Li to disagree with that ๐ โ but I have already > > outlined why it is more complex to do it from the Rx side.) > > In your talk on Monday you called the idea in > draft-decraene-lsr-isis-flooding-speed-01 "receiver driven flow > control". > You don't like that. You want "transmit based flow control". > You argued that you can do "transmit based flow control" on the sender > only. > Therefor your algorithm is merely a "local trick". > And "local tricks" don't need RFCs. I agree with that. > But I don't agree that your algorithm is just a "local trick". > > > In your algorithm, a "sender" sends a number of LSPs to a receiver. > Without waiting for acks (PNSPs). Like in any sliding window protocol. > The sending router keeps an eye on the number of unacked LSPs. > And it determines how fast it can send more LSPs based on the current > number of unacked LSPs. Every time the sender receives a PSNP, it > knows the receiver got a number of LSPs, so it can increase its > send-window again, and then send more LSPs. > Correct ? > > I agree that the core idea of this algorithm makes sense. > After all, it looks a lot like TCP. > I believe the authors of draft-decraene-lsr-isis-flooding-speed were > planning something like that for the next version of their draft. > > > However, I do not agree with the name "tx driven flow control". > I also do not agree that this algorithm is "a local trick". > Therefor I also do not think this algorithm doesn't need to be > documented (in an RFC). > > In your "tx based flow control", the sender (tx) sends LSPs at a rate > that is derived from the rate at which it receives PSNPs. Therefor > it is the sender of the PSNPs that sets the speed of transmission ! > So it is still the receiver (of LSPs) that controls the flow control. > The name "tx based flow control" is a little misleading, imho. > > > It is important to realize that the success of your algorithm actually > depends on the behaviour of the receiver. How does it send PSNPs ? > Does it send one PSNP per received LSP ? Or does it pack multiple acks > in one PSNP ? Does it send a PSNP immediatly, or does it wait a short > time ? Does it try to fill a PSNP to the max (putting ~90 acks in one > PSNP) ? Does the receiver does something in between ? I don't think > the behaviour is specified exactly anywhere. > > I know about an IS-IS implementation from the nineties. When a router > would receive an LSP, it would a) set the SSN bit (for that > LSP/interface), > and b) start the psnp-timer for that interface (if not already running). > The psnp-timer would expire 2 seconds later. The router would then walk > the LSPDB, find all LSPs with the SSN-bit set for that interface. And > then build a PSNP with acks for all those LSPs. The result would be > that: a) the first PSNP would be send 2 seconds (+/- jitter) after > receiving the first LSP, and b) the PSNP would include ~66 acks. (As > a router receiving at full speed would have received 66 LSPs in 2 > seconds). > > For your "tx based flow control" algorithm to work properly, this has > to change. The receiving router must send PSNPs more quickly and more > aggressively. The result would be that there will be less acks in each > PSNP. And thus more PSNPs will be sent. > > This makes us realize: in the current situation, if a router receives > a 1000 LSPs, and sends those LSPs to 64 neighbors, it would receive: > - the 1000 LSPs from an upstream neighbor, plus > - 1000/66 = 16 PSNPs from each downstream neighbor = 64 * 16 = 1024 > PSNPs. > This makes a total of ~2000K PDUs received. > > If routers would send one PSNP per LSP (to have faster flow control), > then the router in this example would receive: > - the 1000 LSPs from an upstream neighbor, plus > - 1000 PSNPs from each downstream neighbor * 16 = 1600 PSNPs. > This makes a total of ~17000 PDUs received. > > The total number of PDUs received on this router would go from 2K PDUs > to 17K PDUs. > > Remember that the problem we're trying to solve here is to make sure > that routers do not get overrun on the receipt side with too many > packets too quickly. It seems an aggressive PSNP-scheme, to achieve > faster flow-control, is actually very counter-productive. > > Of course the algorithm can be tweaked. E.g. TCP sends one ack per > every 2 received segments (if I'm not mistaken). If we do that here, > the number of PDUs would go down from 17K to 9K PDUs. What do you > propose ? How do you want the feedback of PSNPs to be quick, while > maintaining an efficient packing of multiple acks per PSNP ? > [Les:] Base specification defines partialSNPInterval (2 seconds). Clearly w faster flooding we should look at decreasing this timer - but we certainly should not do away with it. > > In any case, the points I'm trying to make here: > *) Your algorithm is not sender-driven, but still receiver-driven. [Les:] My proposal involves changes on the TX side. If you donโt like the name we can certainly find something more appealing. The alternate proposal in the draft is driven by new advertisements from the RX side - hence I called it Rx driven. Yes - code changes are obviously required on the TX side. If you have a better name I am happy to use it. > *) Your algorithm changes/dictates behaviour both on sender and > receiver. > *) Interaction between a sender and a receiver is what we call a > protocol. > If you want to make this work, especially in multi-vendor > environments, > we need to document these algorithms. Aka in an RFC. > [Les:] What I am proposing does not require protocol extensions - therefore no draft is required. Whether a BCP draft is desired is something I am open to considering. Les > Kind regards, > > henk.
- [Lsr] Dynamic flow control for flooding Tony Li
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding Tony Przygienda
- Re: [Lsr] Dynamic flow control for flooding David Lamparter
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding Tony Przygienda
- Re: [Lsr] Dynamic flow control for flooding Robert Raszuk
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding stephane.litkowski
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding Robert Raszuk
- Re: [Lsr] Dynamic flow control for flooding henk.ietf
- Re: [Lsr] Dynamic flow control for flooding Henk Smit
- Re: [Lsr] Dynamic flow control for flooding Robert Raszuk
- Re: [Lsr] Dynamic flow control for flooding Henk Smit
- Re: [Lsr] Dynamic flow control for flooding Robert Raszuk
- Re: [Lsr] Dynamic flow control for flooding Tony Przygienda
- Re: [Lsr] Dynamic flow control for flooding Henk Smit
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding Robert Raszuk
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding stephane.litkowski
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding Les Ginsberg (ginsberg)
- Re: [Lsr] Dynamic flow control for flooding tony.li
- Re: [Lsr] Dynamic flow control for flooding Henk Smit